Ralph Knag | 1fca6ac | 2017-12-05 12:05:57 -0500 | [diff] [blame] | 1 | .. This work is licensed under a Creative Commons Attribution 4.0 International License.
|
| 2 | .. http://creativecommons.org/licenses/by/4.0
|
| 3 |
|
| 4 | .. _cdap-specification:
|
| 5 |
|
| 6 | Component specification (CDAP)
|
| 7 | ==============================
|
| 8 |
|
| 9 | The CDAP component specification contains the following groups of
|
| 10 | information. Many of these are common to both CDAP and Docker components
|
| 11 | and are therefore described in the common specification.
|
| 12 |
|
| 13 | - :any:`Metadata <metadata>`
|
| 14 | - :any:`Interfaces <interfaces>` including the
|
| 15 | associated :any:`Data Formats <data-formats>`
|
| 16 | - :any:`Parameters <parameters>` - for specifying parameters in your
|
| 17 | AppConfig, AppPreferences, and ProgramPreferences to the Designer and
|
| 18 | Policy. This of course is CDAP-specific and is described below.
|
| 19 | - :any:`Auxiliary Details <auxiliary-details>`
|
| 20 | - :any:`List of artifacts <artifacts>`
|
| 21 |
|
| 22 | Current Limitations and TODOs
|
| 23 | -----------------------------
|
| 24 |
|
| 25 | - The integration of DMD is likely to significantly change the
|
| 26 | :any:`Interfaces <interfaces>` section in this specification, see
|
| 27 | :any:`DMaaP abstraction <dmaap-abstraction>`.
|
| 28 |
|
| 29 | .. _parameters:
|
| 30 |
|
| 31 | Parameters
|
| 32 | ----------
|
| 33 |
|
| 34 | There is a ``parameters`` section in your component specification. This
|
| 35 | section contains three optional keys: `app_config <#appconfig>`__,
|
| 36 | `app_preferences <#apppreferences>`__, and
|
| 37 | `propram_preferences <#programpreferences>`__:
|
| 38 |
|
| 39 | ::
|
| 40 |
|
| 41 | "parameters" : {
|
| 42 | "app_config" : [ ...],
|
| 43 | "app_preferences" : [ ...],
|
| 44 | "program_preferences" : [...]
|
| 45 | // any additional keys are ignored
|
| 46 | }
|
| 47 |
|
| 48 | - Each section details the parameters that are a part of each of these
|
| 49 | CDAP constructs (see below).
|
| 50 | - All such parameters will be exposed to the designer and to policy for
|
| 51 | override.
|
| 52 | - These parameters should have default values specified by the
|
| 53 | component developer where necessary, i.e., parameters that *must*
|
| 54 | come from the designer/policy should not have defaults.
|
| 55 | - All of these keys are optional because not every CDAP application
|
| 56 | uses preferences and not every application uses the AppConfig.
|
| 57 | However, you should specify at least one, or else your application
|
| 58 | will have no parameters exposed to policy or to the DCAE designer,
|
| 59 | which means it would be non-configurable.
|
| 60 | - Despite the AppConfig being optional to *specify* in the case that
|
| 61 | you have no parameters in your AppConfig, it is *required for
|
| 62 | processing* in your application. That is because the DCAE platform
|
| 63 | will place important information into your AppConfig as discussed
|
| 64 | below.
|
| 65 |
|
| 66 | Parameter
|
| 67 | ~~~~~~~~~
|
| 68 |
|
| 69 | The following CDAP specific definitions use ``param1`` to refer to the
|
| 70 | common parameter layout in
|
| 71 | :any:`Parameter <parameters>`
|
| 72 |
|
| 73 | AppConfig
|
| 74 | ~~~~~~~~~
|
| 75 |
|
| 76 | The ``app_config`` key refers to the `CDAP AppConfig <http://docs.cask.co/cdap/current/en/reference-manual/http-restful-api/configuration.html>`_.
|
| 77 | It is expected to be a JSON:
|
| 78 |
|
| 79 | ::
|
| 80 |
|
| 81 | "app_config" : [ // list of JSON
|
| 82 | param1, // common parameter layout
|
| 83 | ...
|
| 84 | ]
|
| 85 |
|
| 86 | Unfortunately, at the time of writing, the AppConfig is a Java map of
|
| 87 | ``string:string``, which means you cannot have more complex structures
|
| 88 | (than string) as any value in your AppConfig. However, there is a way to
|
| 89 | bypass this constraint: you can pass a JSON by encoding the JSON as a
|
| 90 | string. E.g., the ``json.dumps()`` and it’s converse ``loads`` methods
|
| 91 | in Python:
|
| 92 |
|
| 93 | ::
|
| 94 |
|
| 95 | >>> import json
|
| 96 | >>> json.dumps({"foo" : "bar"}) # This is a real JSON
|
| 97 | '{"foo": "bar"}' # It is now a string: pass this in as your parameter value
|
| 98 | >>> json.loads('{"foo": "bar"}') # Do the equivelent of this in your application
|
| 99 | {u'foo': u'bar'} # ...and you'll get back a real JSON
|
| 100 | >>>
|
| 101 |
|
| 102 | The final AppConfig (after the designer and policy override parameter
|
| 103 | values) is passed into CDAP’s AppConfig API when starting the
|
| 104 | application.
|
| 105 |
|
| 106 |
|
| 107 | AppPreferences
|
| 108 | ~~~~~~~~~~~~~~
|
| 109 |
|
| 110 | In addition to the CDAP AppConfig, the platform supports `Application Preferences <http://docs.cask.co/cdap/current/en/reference-manual/http-restful-api/preferences.html#set-preferences>`_.
|
| 111 | The format of the ``app_preferences`` value is the same as the above:
|
| 112 |
|
| 113 | ::
|
| 114 |
|
| 115 | "app_preferences" : [ // list of JSON
|
| 116 | param1, // common parameter layout
|
| 117 | ...
|
| 118 | ]
|
| 119 |
|
| 120 | The final Application Preferences JSON (after the designer and policy
|
| 121 | override parameter values) is passed into CDAP’s Preferences API when
|
| 122 | starting your application.
|
| 123 |
|
| 124 |
|
| 125 | ProgramPreferences
|
| 126 | ~~~~~~~~~~~~~~~~~~
|
| 127 |
|
| 128 | Preferences can also be specified `per program <http://docs.cask.co/cdap/current/en/reference-manual/http-restful-api/lifecycle.html#program-lifecycle>`_
|
| 129 | in CDAP. This key’s value is a list of JSON with the following format:
|
| 130 |
|
| 131 | ::
|
| 132 |
|
| 133 | "program_preferences" : [ // note: this is a list of JSON
|
| 134 | {
|
| 135 | "program_id" : "program name 1", // the name of this CDAP program
|
| 136 | "program_type" : "e.g., flows", // "must be one of flows, mapreduce, schedules, spark, workflows, workers, or services",
|
| 137 | "program_pref" : [ // list of JSON
|
| 138 | param1, // common parameter layout
|
| 139 | ...
|
| 140 | ]
|
| 141 | },
|
| 142 | // repeat for each program that receives a program_preferences JSON
|
| 143 | ]
|
| 144 |
|
| 145 | Each ``program_pref`` JSON is passed into the CDAP API as the preference
|
| 146 | for ``program_id``.
|
| 147 |
|
| 148 | NOTE: for CDAP, this section is very likely to change when DMD is
|
| 149 | available. The *future* vision, as per :any:`DMaaP intentionally abstracted <dmaap-abstraction>` is
|
| 150 | that you would publish your data as a series of files on HDFS, and DMD
|
| 151 | will pick them up and send them to the appropriate DMaaP feeds or
|
| 152 | directly when needed.
|
| 153 |
|
| 154 | .. _auxiliary-details:
|
| 155 |
|
| 156 | Auxiliary Details
|
| 157 | -----------------
|
| 158 |
|
| 159 | *auxiliary* contains details about CDAP specific parameters.
|
| 160 |
|
| 161 | +----------------------+----------------------+----------------------+
|
| 162 | | Property Name | Type | Description |
|
| 163 | +======================+======================+======================+
|
| 164 | | streamname | string | *Required*. |
|
| 165 | +----------------------+----------------------+----------------------+
|
| 166 | | artifact_name | string | |
|
| 167 | +----------------------+----------------------+----------------------+
|
| 168 | | artifact_version | string | the version of your |
|
| 169 | | | | CDAP JAR artifact |
|
| 170 | +----------------------+----------------------+----------------------+
|
| 171 | | namespace | string | the CDAP namespace |
|
| 172 | | | | to deploy into, |
|
| 173 | | | | default is ‘default’ |
|
| 174 | +----------------------+----------------------+----------------------+
|
| 175 | | programs | array | contains each CDAP |
|
| 176 | | | | entity represented |
|
| 177 | | | | in the artifact |
|
| 178 | +----------------------+----------------------+----------------------+
|
| 179 | | program_type | string | CDAP entity (eg |
|
| 180 | | | | “flows”) |
|
| 181 | +----------------------+----------------------+----------------------+
|
| 182 | | program_id | string | name of CDAP entity |
|
| 183 | | | | (eg “WhoFlow”) |
|
| 184 | +----------------------+----------------------+----------------------+
|
| 185 |
|
| 186 | Example:
|
| 187 |
|
| 188 | .. code:: json
|
| 189 |
|
| 190 | "auxiliary": {
|
| 191 | "streamname" : "who",
|
| 192 | "artifact_name" : "HelloWorld",
|
| 193 | "artifact_version" : "3.4.3",
|
| 194 | "namespace" : "hw",
|
| 195 | "programs" : [
|
| 196 | {"program_type" : "flows", "program_id" : "WhoFlow"},
|
| 197 | {"program_type" : "services", "program_id" : "Greeting"},
|
| 198 | ...
|
| 199 | ],
|
| 200 | }
|
| 201 |
|
| 202 | The ``programs`` key is identical to the ``program_preferences`` key
|
| 203 | discussed `above <#programpreferences>`__ except:
|
| 204 |
|
| 205 | - each JSON in the list does not contain ``program_pref``
|
| 206 | - this is required! You must include all of your programs in this, as
|
| 207 | it is used to start each program as well as for DCAE to perform
|
| 208 | periodic healthchecks on your application. Don’t forget about your
|
| 209 | services; they are programs too.
|