DCAE Controller documentation DCAEGEN2-213

[dcaegen2.git] / 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
new file mode 100755 (executable)
index 0000000..0f5150f
--- /dev/null
+++ b/docs/sections/components/component-type-cdap.rst
@@ -0,0 +1,90 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.\r
+.. http://creativecommons.org/licenses/by/4.0\r
+\r
+.. _cdap-requirements:\r
+\r
+CDAP Component Requirements\r
+===========================\r
+\r
+This page contains information about CDAP app development in DCAE.\r
+\r
+Uploading your Jar File\r
+-----------------------\r
+\r
+The DCAE component specification has you input your ``jar_url``, the URL\r
+on Nexus to your Jar file. This DCAE controller deploys out of Nexus.\r
+You can upload your jar(s) using the following command, replacing NAME:\r
+\r
+::\r
+\r
+    curl -v --user 'user:password' http://YOUR_NEXUS_RAW_REPO/NAME.jar --upload-file NAME.jar\r
+\r
+During the CLI Tool Usage, in your spec, supply\r
+``http://YOUR_NEXUS_RAW_REPO/NAME.jar`` as the JAR artifact URL.\r
+\r
+Policy Reconfiguration\r
+----------------------\r
+\r
+We support reconfiguration of both AppConfig and AppPreferences.\r
+\r
+For AppConfig, we support CDAPs “update” API to `reconfigure an application <http://docs.cask.co/cdap/current/en/reference-manual/http-restful-api/lifecycle.html#update-an-application%7D%7D>`_.\r
+\r
+For AppPreferences, we:\r
+\r
+1. Stop your programs\r
+\r
+2. Set the new preferences\r
+\r
+3. Start your programs\r
+\r
+At the time of writing, there is no way to update a CDAP application’s\r
+AppConfig or AppPreferences, without a restart, *and notify* the\r
+application. The latter is a future promised feature by CASK—the ability\r
+to update preferences and inform the application that something is\r
+changed (so it repulls). As CDAP currently stands however, given the\r
+above, if you are building a stateful application, you must persist your\r
+state often (e.g., to a CDAP dataset), as you may be restarted at any\r
+time with an updated configuration, or stopped&started at any time with\r
+updated preferences.\r
+\r
+Metrics\r
+-------\r
+\r
+Metrics are pulled from your CDAP application on a periodic basis and\r
+(in the future: pushed to a central DCAE metric store, currently: just\r
+dropped). For this to be useful, your application should provide `metrics <http://docs.cask.co/cdap/current/en/admin-manual/operations/metrics.html>`_.\r
+While nothing in the DCAE runtime enforces that your CDAP application\r
+tracks metrics, your metrics (or lack thereof) will be visible in the\r
+DCAE dashboard and to operations.\r
+\r
+.. _dmaap-abstraction:\r
+\r
+Future DMaaP abstraction\r
+------------------------\r
+\r
+Shown below is our *vision* for how DMaaP is abstracted from component\r
+developers:\r
+\r
+.. figure:: ../images/dmdvision.png\r
+   :alt: Screenshot\r
+\r
+   Screenshot\r
+\r
+Today, this is a vision; it is not in place. Today, each CDAP app is\r
+built with built in assumptions about where they are getting their data\r
+from. Some CDAP apps have the built in assumption of a UEB feed. Some\r
+MR. Some DR. This becomes very difficult to orchestrate when each app in\r
+the catalog has built in data assumptions.\r
+\r
+The goal of this vision is to *decouple* the data plane from the\r
+analytics plane. Analytics should be agnostic to *how* they are\r
+receiving their data beyond “filesystem” or “HTTP”. Analytics developers\r
+shouldn’t have to worry about the data plane, that should be taken care\r
+of by the platform. They should be spending their time on the problem at\r
+hand—the analytic.\r
+\r
+This also allows each CDAP application to have a standard set of\r
+interfaces: HTTP and HDFS: |Screenshot|\r
+\r
+.. |Screenshot| image:: ../images/io.png\r
+\r