From 64559741f071b37556b7745ffa2cdcc25f40af94 Mon Sep 17 00:00:00 2001 From: VENKATESH KUMAR Date: Wed, 29 Apr 2020 18:53:53 -0400 Subject: dcae design doc updates Change-Id: I7145f840d9a7de34bb6a615fe992ba22e1ff0380 Signed-off-by: VENKATESH KUMAR Issue-ID: DCAEGEN2-2024 Issue-ID: DCAEGEN2-1865 Signed-off-by: VENKATESH KUMAR --- docs/sections/components/component-type-cdap.rst | 87 ------------------------ 1 file changed, 87 deletions(-) delete mode 100755 docs/sections/components/component-type-cdap.rst (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 deleted file mode 100755 index f2dce6c5..00000000 --- a/docs/sections/components/component-type-cdap.rst +++ /dev/null @@ -1,87 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 - -.. _cdap-requirements: - -CDAP Component Requirements -=========================== - -This page contains information about CDAP app development in DCAE. - -Uploading your Jar File ------------------------ - -The DCAE component specification has you input your ``jar_url``, the URL -on Nexus to your Jar file. This DCAE controller deploys out of Nexus. -You can upload your jar(s) using the following command, replacing NAME: - -:: - - curl -v --user 'user:password' http://YOUR_NEXUS_RAW_REPO/NAME.jar --upload-file NAME.jar - -During the CLI Tool Usage, in your spec, supply -``http://YOUR_NEXUS_RAW_REPO/NAME.jar`` as the JAR artifact URL. - -Policy Reconfiguration ----------------------- - -We support reconfiguration of both AppConfig and AppPreferences. - -For AppConfig, we support CDAPs “update” API to `reconfigure an application `_. - -For AppPreferences, we: - -1. Stop your programs - -2. Set the new preferences - -3. Start your programs - -At the time of writing, there is no way to update a CDAP application’s -AppConfig or AppPreferences, without a restart, *and notify* the -application. The latter is a future promised feature by CASK—the ability -to update preferences and inform the application that something is -changed (so it repulls). As CDAP currently stands however, given the -above, if you are building a stateful application, you must persist your -state often (e.g., to a CDAP dataset), as you may be restarted at any -time with an updated configuration, or stopped&started at any time with -updated preferences. - -Metrics -------- - -Metrics are pulled from your CDAP application on a periodic basis and -(in the future: pushed to a central DCAE metric store, currently: just -dropped). For this to be useful, your application should provide `metrics `_. -While nothing in the DCAE runtime enforces that your CDAP application -tracks metrics, your metrics (or lack thereof) will be visible in the -DCAE dashboard and to operations. - -.. _dmaap-abstraction: - -Future DMaaP abstraction ------------------------- - -Shown below is our *vision* for how DMaaP is abstracted from component -developers: - -.. 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 -from. Some CDAP apps have the built in assumption of a UEB feed. Some -MR. Some DR. This becomes very difficult to orchestrate when each app in -the catalog has built in data assumptions. - -The goal of this vision is to *decouple* the data plane from the -analytics plane. Analytics should be agnostic to *how* they are -receiving their data beyond “filesystem” or “HTTP”. Analytics developers -shouldn’t have to worry about the data plane, that should be taken care -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: - -.. figure:: ./images/io.png - -- cgit 1.2.3-korg