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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
Onboarding Pre-requisite
========================
Before a component is onboarded into DCAE, the component developer must ensure it
is compliant with ONAP & DCAE goals and requirement in order to correctly be deployed and be managed.
.. _config_binding_service:
Config Binding Service SDK Integration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With Jakarta release, Consul and ConfigBindingService interface has been deprecated from DCAE
All Microservice configuration are resolved through files mounted via Configmap created part of
dcae-services helm chart deployment.
CBS SDK library are available within DCAE which can be used by DCAE Microservices for configuration
retrieval. For details on the API - refer `CBS SDK Java Library
<https://docs.onap.org/projects/onap-dcaegen2/en/latest/sections/sdk/api.html>`__
Its strongly recommended to use CBS SDK library for consistency across DCAE services to retrieve both static and policy driven configuration.
Topic Configuration
~~~~~~~~~~~~~~~~~~~
With Helm flow integration in MOD, topic generation feature is not supported.
Applications are required to identify the topic and feed information as application
configuration.
For application onboarded through MOD, these should be included in the specification file under **parameters**
::
"parameters": [{
"name": "streams_publishes",
"value": "{\"ves-3gpp-fault-supervision\":{\"dmaap_info\":{\"topic_url\":\"http:\/\/message-router:3904\/events\/unauthenticated.SEC_3GPP_FAULTSUPERVISION_OUTPUT\"},\"type\":\"message_router\"},\"ves-3gpp-heartbeat\":{\"dmaap_info\":{\"topic_url\":\"http:\/\/message-router:3904\/events\/unauthenticated.SEC_3GPP_HEARTBEAT_OUTPUT\"},\"type\":\"message_router\"},\"ves-3gpp-performance-assurance\":{\"dmaap_info\":{\"topic_url\":\"http:\/\/message-router:3904\/events\/unauthenticated.SEC_3GPP_PERFORMANCEASSURANCE_OUTPUT\"},\"type\":\"message_router\"},\"ves-3gpp-provisioning\":{\"dmaap_info\":{\"topic_url\":\"http:\/\/message-router:3904\/events\/unauthenticated.SEC_3GPP_PROVISIONING_OUTPUT\"},\"type\":\"message_router\"},\"ves-fault\":{\"dmaap_info\":{\"topic_url\":\"http:\/\/message-router:3904\/events\/unauthenticated.SEC_FAULT_OUTPUT\"},\"type\":\"message_router\"},\"ves-heartbeat\":{\"dmaap_info\":{\"topic_url\":\"http:\/\/message-router:3904\/events\/unauthenticated.SEC_HEARTBEAT_OUTPUT\"},\"type\":\"message_router\"},\"ves-measurement\":{\"dmaap_info\":{\"topic_url\":\"http:\/\/message-router:3904\/events\/unauthenticated.VES_MEASUREMENT_OUTPUT\"},\"type\":\"message_router\"},\"ves-notification\":{\"dmaap_info\":{\"topic_url\":\"http:\/\/message-router:3904\/events\/unauthenticated.VES_NOTIFICATION_OUTPUT\"},\"type\":\"message_router\"},\"ves-other\":{\"dmaap_info\":{\"topic_url\":\"http:\/\/message-router:3904\/events\/unauthenticated.SEC_OTHER_OUTPUT\"},\"type\":\"message_router\"},\"ves-pnfRegistration\":{\"dmaap_info\":{\"topic_url\":\"http:\/\/message-router:3904\/events\/unauthenticated.VES_PNFREG_OUTPUT\"},\"type\":\"message_router\"}}",
"description": "standard http port collector will open for listening;",
"sourced_at_deployment": false,
"policy_editable": false,
"designer_editable": false
}]
For components delivered as Helm directly, it should be specified under **applicationConfig** section in values.yaml
::
streams_publishes:
ves-fault:
dmaap_info:
topic_url:"http://message-router:3904/events/unauthenticated.SEC_FAULT_OUTPUT"
type: message_router
ves-measurement:
dmaap_info:
topic_url: "http://message-router:3904/events/unauthenticated.VES_MEASUREMENT_OUTPUT"
type: message_router
You can find examples of topic and feed configuration used in DCAE components from charts under OOM repository -
https://github.com/onap/oom/tree/master/kubernetes/dcaegen2-services/components
Its recommended to follow similar topic construct for consistency across all DCAE Services. This will also enable using
`SDK DMAAP Java Library
<https://docs.onap.org/projects/onap-dcaegen2/en/latest/sections/sdk/api.html>`__
for easier integration.
DCAE SDK
~~~~~~~~
DCAE has SDK/libraries which can be used for service components for easy integration.
- `Java Library <https://docs.onap.org/projects/onap-dcaegen2/en/latest/sections/sdk/architecture.html>`__
- `Python Modules <https://git.onap.org/dcaegen2/utils/tree/onap-dcae-cbs-docker-client>`__
.. _policy_reconfiguration:
Policy Reconfiguration
----------------------
Policy Framework based reconfiguration is supported via sidecar. The component owners are responsible for
loading the required model and creating policies required.
Once the policies are created, the corresponding policy_id should be listed in the component_spec or helm charts override as below
Component spec must include the policy_info object and list of policy_id to be retrieved
::
"policy_info":{
"policy": [
{
"node_label": "tca_policy_00",
"policy_model_id": "onap.policies.monitoring.cdap.tca.hi.lo.app",
"policy_id": "onap.vfirewall.tca"
},
{
"node_label":"tca_policy_01",
"policy_model_id":"onap.policies.monitoring.cdap.tca.hi.lo.app",
"policy_id":"onap.vdns.tca"
}
]
}
"node_label" is optional and can be ignored
"policy_model_id" refers to model uploaded into policy framework
"policy_id" refers to the instance of policy created for model specified.
When the helm-charts are generated by DCAEMOD/Runtime, the charts will have following property defined in the values.yaml
::
dcaePolicySyncImage: onap/org.onap.dcaegen2.deployments.dcae-services-policy-sync:1.0.1
policies:
policyID: |
'["onap.vfirewall.tca","onap.vdns.tca"]'
When using dcaegen2-services-common templates, the presence of **policies** property will deploy policy-sidecar automatically which will
periodically pull configuration from Policy framework and make it available shared mountpoint to microservice container.
More information on Policy side car can be found on this wiki - https://wiki.onap.org/display/DW/Policy+function+as+Sidecar
.. note::
When using DCAE CBS SDK, policy config retrieval is supported natively by the library
.. _docker_images:
Docker Images
-------------
Docker images must be pushed to the environment specific Nexus
repository. This requires tagging your build with the full name of you
image which includes the Nexus repository name.
For ONAP microservices, the components images are expected to pushed into ONAP nexus
part of `ONAP CI jobs <https://wiki.onap.org/display/DW/Using+Standard+Jenkins+Job+%28JJB%29+Templates>`__
Helm Chart
----------
Components being delivered under ONAP/OOM must adopt dcaegen2-common-services template.
Information about using the common templates to deploy a microservice can be
found in :doc:`Helm to deploy DCAE Microservices <./dcaeservice_helm_template>`.
.. _operation_requirement:
Operational Requirement
-----------------------
Logging
~~~~~~~
All ONAP MS logging should follow logging specification defined by `SECCOM <https://wiki.onap.org/display/DW/Jakarta+Best+Practice+Proposal+for+Standardized+Logging+Fields+-+v2>`__
The application log configuration must enable operation to choose if to be written into file or stdout or both during deployment.
S3P
~~~
ONAP S3P (all scaling/resiliency/security/maintainability) goals should meet at the minimum level defined for DCAE project for the targeted release
If the component is stateful, it should persist its state on external store (eg. pg, redis) to allow support for scaling and
resiliency. This should be important design criteria for the component.
|
