docs/sections/components/component-type-cdap.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.\r
   2 .. http://creativecommons.org/licenses/by/4.0\r
   3 \r
   4 .. _cdap-requirements:\r
   5 \r
   6 CDAP Component Requirements\r
   7 ===========================\r
   8 \r
   9 This page contains information about CDAP app development in DCAE.\r
  10 \r
  11 Uploading your Jar File\r
  12 -----------------------\r
  13 \r
  14 The DCAE component specification has you input your ``jar_url``, the URL\r
  15 on Nexus to your Jar file. This DCAE controller deploys out of Nexus.\r
  16 You can upload your jar(s) using the following command, replacing NAME:\r
  17 \r
  18 ::\r
  19 \r
  20     curl -v --user 'user:password' http://YOUR_NEXUS_RAW_REPO/NAME.jar --upload-file NAME.jar\r
  21 \r
  22 During the CLI Tool Usage, in your spec, supply\r
  23 ``http://YOUR_NEXUS_RAW_REPO/NAME.jar`` as the JAR artifact URL.\r
  24 \r
  25 Policy Reconfiguration\r
  26 ----------------------\r
  27 \r
  28 We support reconfiguration of both AppConfig and AppPreferences.\r
  29 \r
  30 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
  31 \r
  32 For AppPreferences, we:\r
  33 \r
  34 1. Stop your programs\r
  35 \r
  36 2. Set the new preferences\r
  37 \r
  38 3. Start your programs\r
  39 \r
  40 At the time of writing, there is no way to update a CDAP application’s\r
  41 AppConfig or AppPreferences, without a restart, *and notify* the\r
  42 application. The latter is a future promised feature by CASK—the ability\r
  43 to update preferences and inform the application that something is\r
  44 changed (so it repulls). As CDAP currently stands however, given the\r
  45 above, if you are building a stateful application, you must persist your\r
  46 state often (e.g., to a CDAP dataset), as you may be restarted at any\r
  47 time with an updated configuration, or stopped&started at any time with\r
  48 updated preferences.\r
  49 \r
  50 Metrics\r
  51 -------\r
  52 \r
  53 Metrics are pulled from your CDAP application on a periodic basis and\r
  54 (in the future: pushed to a central DCAE metric store, currently: just\r
  55 dropped). For this to be useful, your application should provide `metrics <http://docs.cask.co/cdap/current/en/admin-manual/operations/metrics.html>`_.\r
  56 While nothing in the DCAE runtime enforces that your CDAP application\r
  57 tracks metrics, your metrics (or lack thereof) will be visible in the\r
  58 DCAE dashboard and to operations.\r
  59 \r
  60 .. _dmaap-abstraction:\r
  61 \r
  62 Future DMaaP abstraction\r
  63 ------------------------\r
  64 \r
  65 Shown below is our *vision* for how DMaaP is abstracted from component\r
  66 developers:\r
  67 \r
  68 .. figure:: ../images/dmdvision.png\r
  69    :alt: Screenshot\r
  70 \r
  71    Screenshot\r
  72 \r
  73 Today, this is a vision; it is not in place. Today, each CDAP app is\r
  74 built with built in assumptions about where they are getting their data\r
  75 from. Some CDAP apps have the built in assumption of a UEB feed. Some\r
  76 MR. Some DR. This becomes very difficult to orchestrate when each app in\r
  77 the catalog has built in data assumptions.\r
  78 \r
  79 The goal of this vision is to *decouple* the data plane from the\r
  80 analytics plane. Analytics should be agnostic to *how* they are\r
  81 receiving their data beyond “filesystem” or “HTTP”. Analytics developers\r
  82 shouldn’t have to worry about the data plane, that should be taken care\r
  83 of by the platform. They should be spending their time on the problem at\r
  84 hand—the analytic.\r
  85 \r
  86 This also allows each CDAP application to have a standard set of\r
  87 interfaces: HTTP and HDFS: |Screenshot|\r
  88 \r
  89 .. |Screenshot| image:: ../images/io.png\r
  90 \r