1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
.. 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 <http://docs.cask.co/cdap/current/en/reference-manual/http-restful-api/lifecycle.html#update-an-application%7D%7D>`_.
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 <http://docs.cask.co/cdap/current/en/admin-manual/operations/metrics.html>`_.
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
:alt: Screenshot
Screenshot
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: |Screenshot|
.. |Screenshot| image:: ../images/io.png
|
