1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
2 .. http://creativecommons.org/licenses/by/4.0
5 .. _component_specification:
7 What is Component Specification?
8 ================================
10 This page will discuss categories defined in :any:`component specification schema <dcae-component-schema>` and their usage.
13 Meta Schema Definition
14 ----------------------
17 The “Meta Schema” implementation defines how component specification
18 JSON schemas can be written to define user input. It is itself a JSON
19 schema (thus it is a “meta schema”). It requires the name of the
20 component entry, component type (either ‘cdap’ or ‘docker’) and a
21 description under “self” object. The meta schema version must be
22 specified as the value of the “version” key. Then the input schema
25 There are four types of schema descriptions objects - jsonschema for
26 inline standard JSON Schema definitions of JSON inputs, delimitedschema
27 for delimited data input using a JSON description defined by AT&T,
28 unstructured for unstructured text, and reference that allows a pointer
29 to another artifact for a schema. The reference allows for XML and Protocol Buffer schema,
30 but can be used as a pointer to JSON, Delimited Format, and Unstructured
33 .. _component_metadata:
38 Metadata refers to the properties found under the ``self`` JSON. This
39 group of properties is used to uniquely identify this component
40 specification and identify the component that this specification is used
49 "name": "yourapp.component.kpi_anomaly",
50 "description": "Classifies VNF KPI data as anomalous",
51 "component_type": "docker"
56 +-------------+--------+----------------+
57 | Property | Type | Description |
59 +=============+========+================+
60 | version | string | *Required*. |
65 +-------------+--------+----------------+
66 | name | string | *Required*. |
78 +-------------+--------+----------------+
79 | description | string | *Required* |
80 | | | Human-readable |
89 +-------------+--------+----------------+
90 | component_t\| string | *Required* |
105 +-------------+--------+----------------+
112 Interfaces are the JSON objects found under the ``streams`` key and the
113 ``services`` key. These are used to describe the interfaces that the
114 component uses and the interfaces that the component provides. The
115 description of each interface includes the associated :any:`data
116 format <data-formats>`.
121 - The ``streams`` JSON is for specifying data produced for consumption
122 by other components, and the streams expected to subscribe to that is
123 produced by other components. These are “fire and forget” type
124 interfaces where the publisher of a stream does not expect or parse a
125 response from the subscriber.
126 - The term ``stream`` here is abstract and neither refers to “CDAP
127 streams” or “DMaaP feeds”. While a stream is very likely a DMaaP
128 feed, it could be a direct stream of data being routed via HTTP too.
129 It abstractly refers to a sequence of data leaving a publisher.
130 - Streams have anonymous publish/subscribe semantics, which decouples
131 the production of information from its consumption. Like the component
132 specification, the data format specification is represented/validated against this
133 `Data Format json schema <https://gerrit.onap.org/r/gitweb?p=dcaegen2/platform/cli.git;a=blob;f=component-json-schemas/data-format/dcae-cli-v1/data-format-schema.json;h=be1568291300305c7adb9a8d244d39f9e6ddadbd;hb=HEAD>`__
134 - In general, components are not aware of who they are communicating
136 - Instead, components that are interested in data, subscribe to the
137 relevant stream; components that generate data publish to the
139 - There can be multiple publishers and subscribers to a stream. Streams
140 are intended for unidirectional, streaming communication.
142 Streams interfaces that implement an HTTP endpoint must support POST.
144 Streams are split into:
146 +-------------+----+----------+
147 | Property | Ty\| Descript\|
149 +=============+====+==========+
150 | subscribes | JS\| *Require\|
168 +-------------+----+----------+
169 | publishes | JS\| *Require\|
183 +-------------+----+----------+
194 "format": "dcae.vnf.kpi",
196 "route": "/data", // for CDAP this value is not used
202 This describes that ``yourapp.component.kpi_anomaly`` exposes an HTTP
203 endpoint called ``/data`` which accepts requests that have the data
204 format of ``dcae.vnf.kpi`` version ``1.0.0``.
206 ``subscribes`` Schema:
208 +-------------+----+--------------------+
209 | Property | Ty\| Descript\ |
211 +=============+====+====================+
212 | format | st\| *Require\ |
224 +-------------+----+--------------------+
225 | version | st\| *Require\ |
238 +-------------+----+--------------------+
239 | route | st\| *Require\ |
252 +-------------+----+--------------------+
253 | config_key | st\| *Require\ |
256 | | | message_router\ |
267 +-------------+----+--------------------+
268 | type | st\| *Require\ |
274 | | | ``message_router`` |
276 | | | ``data_router`` |
279 +-------------+----+--------------------+
286 Message router subscribers are http clients rather than http services
287 and performs a http a ``GET`` call. Thus, message router subscribers
288 description is structured like message router publishers and requires
295 "format": "dcae.some-format",
297 "config_key": "some_format_handle",
298 "type": "message router"
309 Data router subscribers are http or https services that handle ``PUT``
310 requests from data router. Developers must provide the ``route`` or url
311 path/endpoint that is expected to handle data router requests. This will
312 be used to construct the delivery url needed to register the subscriber
313 to the provisioned feed. Developers must also provide a ``config_key``
314 because there is dynamic configuration information associated with the
315 feed that the application will need e.g. username and password. See the
316 page on :any:`DMaaP connection objects <dmaap-data-router>` for more details on
317 the configuration information.
319 Example (not tied to the larger example):
325 "config_key": "some-sub-dr",
326 "format": "sandbox.platform.any",
327 "route": "/identity",
328 "type": "data_router",
339 Kafka subscribers are clients fetching data directly from kafka.
347 "format": "dcae.some-format",
349 "config_key": "some_format_handle",
365 "format": "yourapp.format.integerClassification",
367 "config_key": "prediction",
372 This describes that ``yourapp.component.kpi_anomaly`` publishes by making
373 POST requests to streams that support the data format
374 ``yourapp.format.integerClassification`` version ``1.0.0``.
376 ``publishes`` Schema:
378 +-------------+----+--------------------+
379 | Property | Ty\| Descript\ |
381 +=============+====+====================+
382 | format | st\| *Require\ |
394 +-------------+----+--------------------+
395 | version | st\| *Require\ |
408 +-------------+----+--------------------+
409 | config_key | st\| *Require\ |
435 +-------------+----+--------------------+
436 | type | st\| *Require\ |
442 | | | ``message_router`` |
444 | | | ``data_router`` |
447 +-------------+----+--------------------+
454 Message router publishers are http clients of DMaap message_router.
455 Developers must provide a ``config_key`` because there is dynamic
456 configuration information associated with the feed that the application
457 needs to receive e.g. topic url, username, password. See the page on
458 :any:`DMaaP connection objects <dmaap-message-router>` for more details on
459 the configuration information.
461 Example (not tied to the larger example):
468 "config_key": "some-pub-mr",
469 "format": "sandbox.platform.any",
470 "type": "message_router",
480 Data router publishers are http clients that make ``PUT`` requests to
481 data router. Developers must also provide a ``config_key`` because there
482 is dynamic configuration information associated with the feed that the
483 application will need to receive e.g. publish url, username, password.
484 See the page on :any:`DMaaP connection objects <dmaap-data-router>` for more details on
485 the configuration information.
487 Example (not tied to the larger example):
494 "config_key": "some-pub-dr",
495 "format": "sandbox.platform.any",
496 "type": "data_router",
506 Kafka publishers are clients publishing data directly to kafka.
514 "format": "dcae.some-format",
516 "config_key": "some_format_handle",
525 Refer to this :doc:`Quick Reference <streams-grid>` for a
526 comparison of the Streams ‘Publishes’ and ‘Subscribes’ sections.
531 - The publish / subscribe model is a very flexible communication
532 paradigm, but its many-to-many one-way transport is not appropriate
533 for RPC request / reply interactions, which are often required in a
535 - Request / reply is done via a Service, which is defined by a pair of
536 messages: one for the request and one for the reply.
538 Services are split into:
540 +-------------+----+----------+
541 | Property | Ty\| Descript\|
543 +=============+====+==========+
544 | calls | JS\| *Require\|
557 +-------------+----+----------+
558 | provides | JS\| *Require\|
572 +-------------+----+----------+
577 The JSON ``services/calls`` is for specifying that the component relies
578 on an HTTP(S) service—the component sends that service an HTTP request,
579 and that service responds with an HTTP reply. An example of this is how
580 string matching (SM) depends on the AAI Broker. SM performs a
581 synchronous REST call to the AAI broker, providing it the VMNAME of the
582 VNF, and the AAI Broker responds with additional details about the VNF.
583 This dependency is expressed via ``services/calls``. In contrast, the
584 output of string matching (the alerts it computes) is sent directly to
585 policy as a fire-and-forget interface, so that is an example of a
594 "config_key": "vnf-db",
596 "format": "dcae.vnf.meta",
600 "format": "dcae.vnf.kpi",
607 This describes that ``yourapp.component.kpi_anomaly`` will make HTTP
608 calls to a downstream component that accepts requests of data format
609 ``dcae.vnf.meta`` version ``1.0.0`` and is expecting the response to be
610 ``dcae.vnf.kpi`` version ``1.0.0``.
614 +-------------+----+----------+
615 | Property | Ty\| Descript\|
617 +=============+====+==========+
618 | request | JS\| *Require\|
630 +-------------+----+----------+
631 | response | JS\| *Require\|
643 +-------------+----+----------+
644 | config_key | st\| *Require\|
667 +-------------+----+----------+
669 The JSON object schema for both ``request`` and ``response``:
671 +-------------+----+----------+
672 | Property | Ty\| Descript\|
674 +=============+====+==========+
675 | format | st\| *Require\|
687 +-------------+----+----------+
688 | version | st\| *Require\|
701 +-------------+----+----------+
713 "route": "/score-vnf",
715 "format": "dcae.vnf.meta",
719 "format": "yourapp.format.integerClassification",
725 This describes that ``yourapp.component.kpi_anomaly`` provides a service
726 interface and it is exposed on the ``/score-vnf`` HTTP endpoint. The
727 endpoint accepts requests that have the data format ``dcae.vnf.meta``
728 version ``1.0.0`` and gives back a response of
729 ``yourapp.format.integerClassification`` version ``1.0.0``.
731 ``provides`` Schema for a Docker component:
733 +-------------+----+----------+
734 | Property | Ty\| Descript\|
736 +=============+====+==========+
737 | request | JS\| *Require\|
747 +-------------+----+----------+
748 | response | JS\| *Require\|
758 +-------------+----+----------+
759 | route | st\| *Require\|
769 +-------------+----+----------+
771 The JSON object schema for both ``request`` and ``response``:
773 +-------------+----+----------+
774 | Property | Ty\| Descript\|
776 +=============+====+==========+
777 | format | st\| *Require\|
789 +-------------+----+----------+
790 | version | st\| *Require\|
803 +-------------+----+----------+
805 Note, for CDAP, there is a slight variation due to the way CDAP exposes
810 "provides":[ // note this is a list of JSON
814 "service_name":"name CDAP service",
815 "service_endpoint":"greet", // E.g the URL is /services/service_name/methods/service_endpoint
816 "verb":"GET" // GET, PUT, or POST
820 ``provides`` Schema for a CDAP component:
822 +-------------+----+-----------+
823 | Property | Ty\| Descript\ |
825 +=============+====+===========+
826 | request | JS\| *Require\ |
838 +-------------+----+-----------+
839 | response | JS\| *Require\ |
849 +-------------+----+-----------+
850 | service_nam\| st\| *Require\ |
857 +-------------+----+-----------+
858 | service_end | st\| *Require\ |
869 +-------------+----+-----------+
870 | verb | st\| *Require\ |
875 +-------------+----+-----------+
877 .. _common-specification-parameters:
882 ``parameters`` is where to specify the component’s application
883 configuration parameters that are not connection information.
885 +---------------+------------+----------------------------------+
886 | Property Name | Type | Description |
887 +===============+============+==================================+
888 | parameters | JSON array | Each entry is a parameter object |
889 +---------------+------------+----------------------------------+
891 Parameter object has the following available properties:
893 +--------------+----+----------+------+
894 | Property | Ty\| Descript\| Defa\|
895 | Name | pe | ion | ult |
896 +==============+====+==========+======+
897 | name | st\| *Require\| |
910 +--------------+----+----------+------+
911 | value | an\| *Require\| |
920 +--------------+----+----------+------+
921 | description | st\| *Require\| |
923 | | ng | Human-re\| |
934 +--------------+----+----------+------+
935 | type | st\| The | |
936 | | ri\| required | |
942 +--------------+----+----------+------+
943 | required | bo\| An | true |
944 | | ol\| optional | |
945 | | ea\| key that | |
955 +--------------+----+----------+------+
956 | constraints | ar\| The | |
957 | | ra\| optional | |
969 +--------------+----+----------+------+
970 | entry_schem\ | st\| The | |
971 | a | ri\| optional | |
972 | | ng | key that | |
997 +--------------+----+----------+------+
998 | designer_ed\ | bo\| An | |
999 | itable | ol\| optional | |
1000 | | ea\| key that | |
1001 | | n | declares | |
1012 +--------------+----+----------+------+
1013 | sourced_at_d\| bo\| An | |
1014 | eployment | ol\| optional | |
1015 | | ea\| key that | |
1016 | | n | declares | |
1028 +--------------+----+----------+------+
1029 | policy_edit\ | bo\| An | |
1030 | able | ol\| optional | |
1031 | | ea\| key that | |
1032 | | n | declares | |
1043 +--------------+----+----------+------+
1044 | policy_sche\ | ar\| The | |
1045 | ma | ra\| optional | |
1054 +--------------+----+----------+------+
1062 "name": "threshold",
1064 "description": "Probability threshold to exceed to be anomalous"
1068 Many of the parameter properties have been copied from TOSCA model
1069 property definitions and are to be used for service design composition
1070 and policy creation. See `section 3.5.8 *Property
1071 definition* <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.1/TOSCA-Simple-Profile-YAML-v1.1.html>`__.
1073 The property ``constraints`` is a list of objects where each constraint
1076 +--------------+----+----------+
1077 | Property | Ty\| Descript\|
1079 +==============+====+==========+
1080 | equal | | Constrai\|
1094 +--------------+----+----------+
1095 | greater_tha\ | nu\| Constrai\|
1110 +--------------+----+----------+
1111 | greater_or_e\| nu\| Constrai\|
1127 +--------------+----+----------+
1128 | less_than | nu\| Constrai\|
1143 +--------------+----+----------+
1144 | less_or_equ\ | nu\| Constrai\|
1160 +--------------+----+----------+
1161 | valid_value\ | ar\| Constrai\|
1175 +--------------+----+----------+
1176 | length | nu\| Constrai\|
1187 +--------------+----+----------+
1188 | min_length | nu\| Constrai\|
1200 +--------------+----+----------+
1201 | max_length | nu\| Constrai\|
1213 +--------------+----+----------+
1215 ``threshold`` is the configuration parameter and will get set to 0.75
1216 when the configuration gets generated.
1218 The property ``policy_schema`` is a list of objects where each
1219 policy_schema object:
1221 +-------------+----+----------+------+
1222 | Property | Ty\| Descript\| Defa\|
1223 | Name | pe | ion | ult |
1224 +=============+====+==========+======+
1225 | name | st\| *Require\| |
1227 | | ng | paramete\| |
1230 +-------------+----+----------+------+
1231 | value | st\| default | |
1233 | | ng | for the | |
1236 +-------------+----+----------+------+
1237 | description | st\| paramete\| |
1239 | | ng | descript\| |
1241 +-------------+----+----------+------+
1242 | type | en\| *Require\| |
1259 +-------------+----+----------+------+
1260 | required | bo\| is | true |
1261 | | ol\| paramete\| |
1263 | | n | required | |
1265 +-------------+----+----------+------+
1266 | constraints | ar\| The | |
1267 | | ra\| optional | |
1279 +-------------+----+----------+------+
1280 | entry_schem\| st\| The | |
1281 | a | ri\| optional | |
1282 | | ng | key that | |
1322 +-------------+----+----------+------+
1371 +-------------+----+----------+------+
1409 +-------------+----+----------+------+
1441 +-------------+----+----------+------+
1449 ``artifacts`` contains a list of artifacts associated with this
1450 component. For Docker, this is the full path (including the registry) to
1451 the Docker image. For CDAP, this is the full path to the CDAP jar.
1453 +---------------+------------+---------------------------------+
1454 | Property Name | Type | Description |
1455 +===============+============+=================================+
1456 | artifacts | JSON array | Each entry is a artifact object |
1457 +---------------+------------+---------------------------------+
1459 ``artifact`` Schema:
1461 +---------------+--------+--------------------------------------------+
1462 | Property Name | Type | Description |
1463 +===============+========+============================================+
1464 | uri | string | *Required*. Uri to the artifact, full path |
1465 +---------------+--------+--------------------------------------------+
1466 | type | string | *Required*. ``docker image`` or ``jar`` |
1467 +---------------+--------+--------------------------------------------+
1473 New V3 version of component spec schema introduced -
1474 https://github.com/onap/dcaegen2-platform/blob/master/mod/component-json-schemas/component-specification/dcae-cli-v3/component-spec-schema.json
1476 - Added new “helm” object under “auxilary\_docker” properties
1478 - Includes “applicationEnv”
1480 - Includes “service” definition
1482 - Readiness Configuration support
1484 - docker\_healthcheck\_http
1486 - Added HTTP/HTTPS for supported protocol enum list
1490 - Added “initialDelaySeconds”
1492 - docker\_healthcheck\_script
1494 - Added “initialDelaySeconds”
1499 Component developers are required to provide a way for the platform to
1500 periodically check the health of their running components. The
1501 details of the definition used by your component is to be provided
1502 through the :any:`Docker auxiliary specification <docker-auxiliary-details>`.
1504 The information contained in the auxilary_docker field is the Docker component specification schema. Some properties of the docker component specification include -
1506 healthcheck : Defines the health check that Consul should perform for this component
1508 log_info : Component specific details for logging, includes the path in the container where logs are written that can also be used for logstash/kibana style reporting.
1510 ports : Port mapping to be used for Docker containers. Each entry is of the format <container port>:<host port>.
1512 tls_info : Component information for use of tls certificates, where they will be available, whether or not to use them
1514 policy : Information for Policy configuration and reconfiguration
1516 databases: Information about databases the application should connect to
1518 volumes: Contains information on volume mapping for the docker containers
1525 "auxilary_docker": {
1526 "title": "Docker component specification schema",
1530 "description": "Define the health check that Consul should perfom for this component",
1533 { "$ref": "#/definitions/docker_healthcheck_http" },
1534 { "$ref": "#/definitions/docker_healthcheck_script" }
1538 "description": "Port mapping to be used for Docker containers. Each entry is of the format <container port>:<host port>.",
1545 "description": "Component specific details for logging",
1549 "description": "The path in the container where the component writes its logs. If the component is following the EELF requirements, this would be the directory where the four EELF files are being written. (Other logs can be placed in the directory--if their names in '.log', they'll also be sent into ELK.)",
1552 "alternate_fb_path": {
1553 "description": "By default, the log volume is mounted at /var/log/onap/<component_type> in the sidecar container's file system. 'alternate_fb_path' allows overriding the default. Will affect how the log data can be found in the ELK system.",
1557 "additionalProperties": false
1560 "description": "Component information to use tls certificates",
1564 "description": "The path in the container where the component certificates will be placed by the init container",
1568 "description": "Boolean flag to determine if the application is using tls certificates",
1571 "use_external_tls": {
1572 "description": "Boolean flag to determine if the application is using tls certificates for external communication",
1577 "cert_directory","use_tls"
1579 "additionalProperties": false
1582 "description": "The databases the application is connecting to using the pgaas",
1584 "additionalProperties": {
1594 "description": "Only value of docker is supported at this time.",
1599 "description": "Script command that will be executed for policy reconfiguration",
1604 "trigger_type","script_path"
1606 "additionalProperties": false
1609 "description": "Volume mapping to be used for Docker containers. Each entry is of the format below",
1614 { "$ref": "#/definitions/host_path_volume" },
1615 { "$ref": "#/definitions/config_map_volume" }
1623 "additionalProperties": false