From d2cd31b73c0282f7aafd5b4adada00c0f4533d61 Mon Sep 17 00:00:00 2001 From: Ralph Knag Date: Mon, 2 Apr 2018 16:27:46 -0400 Subject: Onboarding documentation update for CLI Change-Id: I1d4d0111063ea62c3759aa9b7232998b70229644 Issue-ID: DCAEGEN2-350 Signed-off-by: Ralph Knag --- docs/sections/components/component-type-cdap.rst | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) (limited to 'docs/sections/components/component-type-cdap.rst') diff --git a/docs/sections/components/component-type-cdap.rst b/docs/sections/components/component-type-cdap.rst index 0f5150fd..f2dce6c5 100755 --- a/docs/sections/components/component-type-cdap.rst +++ b/docs/sections/components/component-type-cdap.rst @@ -65,10 +65,7 @@ Future DMaaP abstraction Shown below is our *vision* for how DMaaP is abstracted from component developers: -.. figure:: ../images/dmdvision.png - :alt: Screenshot - - Screenshot +.. figure:: ./images/dmdvision.png Today, this is a vision; it is not in place. Today, each CDAP app is built with built in assumptions about where they are getting their data @@ -84,7 +81,7 @@ of by the platform. They should be spending their time on the problem at hand—the analytic. This also allows each CDAP application to have a standard set of -interfaces: HTTP and HDFS: |Screenshot| +interfaces: HTTP and HDFS: -.. |Screenshot| image:: ../images/io.png +.. figure:: ./images/io.png -- cgit 1.2.3-korg