blob: 6b5d5b4298b1f46a0b0a81462d271eb96ff74275 [file] [log] [blame]
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001.. This work is licensed under a Creative Commons Attribution 4.0 International License.
2.. http://creativecommons.org/licenses/by/4.0
3.. Copyright 2020 ONAP
4
5.. _docs_vFW_CNF_CDS:
6
mrichommee4643892020-11-30 18:31:29 +01007:orphan:
Samuli Silviusa58b0b42020-02-18 10:00:47 +02008
9vFirewall CNF Use Case
10----------------------
11
12Source files
13~~~~~~~~~~~~
14- Heat/Helm/CDS models: `vFW_CNF_CDS Model`_
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +010015- Automation Scripts: `vFW_CNF_CDS Automation`_
Samuli Silviusa58b0b42020-02-18 10:00:47 +020016
17Description
18~~~~~~~~~~~
19This use case is a combination of `vFW CDS Dublin`_ and `vFW EDGEX K8S`_ use cases. The aim is to continue improving Kubernetes based Network Functions (a.k.a CNF) support in ONAP. Use case continues where `vFW EDGEX K8S`_ left and brings CDS support into picture like `vFW CDS Dublin`_ did for the old vFW Use case. Predecessor use case is also documented here `vFW EDGEX K8S In ONAP Wiki`_.
20
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +010021This use case shows how to onboard helm packages and to instantiate them with help of ONAP. Following improvements were made in the vFW CNF Use Case:
Samuli Silviusa58b0b42020-02-18 10:00:47 +020022
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +010023- vFW Kubernetes Helm charts support overrides (previously mostly hardcoded values)
Konrad Bańkac01b1fb2020-05-27 15:25:56 +020024- SDC accepts Onboarding Package with many helm packages what allows to keep decomposition of service instance similar to `vFW CDS Dublin`_
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +010025- Compared to `vFW EDGEX K8S`_ use case **MACRO** workflow in SO is used instead of VNF a'la carte workflow
26- No VNF data preloading used, instead resource-assignment feature of CDS is used
27- CDS is used to resolve instantiation time parameters (Helm overrides)
deen1985589467c2020-12-28 10:40:03 +010028 * IP addresses with IPAM
29 * Unique names for resources with ONAP naming service
30 * CDS is used to create and upload **multicloud/k8s profile** as part of instantiation flow
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +010031- Combined all models (Heat, Helm, CBA) in to same git repo and a created single onboarding package `vFW_CNF_CDS Model`_
32- Use case does not contain Closed Loop part of the vFW demo.
Samuli Silviusa58b0b42020-02-18 10:00:47 +020033
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +010034All changes to related ONAP components and Use Case can be found in the following tickets:
35
36- `REQ-182`_
37- `REQ-341`_
38
39**Since Guilin ONAP supports Helm packages as a native onboarding artifacts and SO natively orchestrates Helm packages what brings significant advantages in the future. Also since this release ONAP has first mechanisms for monitoring of the status of deployed CNF resources**.
Samuli Silviusa58b0b42020-02-18 10:00:47 +020040
41The vFW CNF Use Case
42~~~~~~~~~~~~~~~~~~~~
Konrad Bańkacc67f632020-03-12 12:09:13 +010043The vFW CNF CDS use case shows how to instantiate multiple CNF instances in similar way as VNFs bringing CNFs closer to first class citizens in ONAP.
Samuli Silviusa58b0b42020-02-18 10:00:47 +020044
Konrad Bańkacc67f632020-03-12 12:09:13 +010045One of the biggest practical change compared to the old demos (any ONAP demo) is that whole network function content (user provided content) is collected to one place and more importantly into git repository (`vFW_CNF_CDS Model`_) that provides version control (that is pretty important thing). That is very basic thing but unfortunately this is a common problem when running any ONAP demo and trying to find all content from many different git repositories and even some files only in ONAP wiki.
Samuli Silviusa58b0b42020-02-18 10:00:47 +020046
47Demo git directory has also `Data Dictionary`_ file (CDS model time resource) included.
48
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +020049Another founding idea from the start was to provide complete content in single onboarding package available directly from that git repository. Not any revolutionary idea as that's the official package format ONAP supports and all content supposed to be in that same package for single service regardless of the models and closed loops and configurations etc.
Samuli Silviusa58b0b42020-02-18 10:00:47 +020050
Konrad Bańkacc67f632020-03-12 12:09:13 +010051Following table describes all the source models to which this demo is based on.
Samuli Silviusa58b0b42020-02-18 10:00:47 +020052
53=============== ================= ===========
54Model Git reference Description
55--------------- ----------------- -----------
Konrad Bańkacc67f632020-03-12 12:09:13 +010056Heat `vFW_NextGen`_ Heat templates used in original vFW demo but split into multiple vf-modules
Samuli Silviusa58b0b42020-02-18 10:00:47 +020057Helm `vFW_Helm Model`_ Helm templates used in `vFW EDGEX K8S`_ demo
58CDS model `vFW CBA Model`_ CDS CBA model used in `vFW CDS Dublin`_ demo
59=============== ================= ===========
60
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +010061.. note:: Since the Guilin release `vFW_CNF_CDS Model`_ contains sources that allow to model and instantiate CNF with VNF/Heat orchestration approach (Frankfurt) and with native Helm orchestration approach. Please follow README.txt description and further documentation here to generate and select appropriate onboarding package which will leverage appropriate SO orchestration path.
Samuli Silviusa58b0b42020-02-18 10:00:47 +020062
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +020063Modeling Onboarding Package/Helm
64................................
Samuli Silviusa58b0b42020-02-18 10:00:47 +020065
Konrad Bańkacc67f632020-03-12 12:09:13 +010066The starting point for this demo was Helm package containing one Kubernetes application, see `vFW_Helm Model`_. In this demo we decided to follow SDC/SO vf-module concept the same way as original vFW demo was split into multiple vf-modules instead of one (`vFW_NextGen`_). The same way we splitted Helm version of vFW into multiple Helm packages each matching one dedicated vf-module.
Samuli Silviusa58b0b42020-02-18 10:00:47 +020067
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +010068The Guilin version of the `vFW_CNF_CDS Model`_ contains files required to create **VSP onboarding packages in two formats**: the **Dummy Heat** (available in Frankfurt release already) one that considers association of each Helm package with dummy heat templates and the **Native Helm** one where each Helm package is standalone and is natively understood in consequence by SO. For both variants of VSP Helm packages are matched to the vf-module concept, so basically each Helm application after instantiation is visible to ONAP as a separate vf-module. The chosen format for onboarding has **crucial** role in the further orchestration approach applied for Helm package instantiation. The **Dummy Heat** will result with orchestration through the **Openstack Adapter** component of SO while **Native Helm** will result with **CNF Adapter**. Both approaches will result with instantiation of the same CNF, however the **Native Helm** approach will be enhanced in the future releases while **Dummy Heat** approach will become deprecated in the future.
Samuli Silviusa58b0b42020-02-18 10:00:47 +020069
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +010070Produced **Dummy Heat** VSP onboarding package `Creating Onboarding Package`_ format has following MANIFEST file (package_dummy/MANIFEST.json). The Helm package is delivered as CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT package through SDC and SO. Dummy heat templates are matched to Helm packages by the same prefix <vf_module_label> of the file name that for both dummy Heat teamplate and for CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT must be the same, like i.e. *vpg* vf-module in the manifest file below. The name of the CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT artifact is predefined and needs to match the pattern: <vf_module_label>_cloudtech_k8s_charts.tgz. More examples can be found in `Modeling Onboarding Package/Helm`_ section.
Samuli Silviusa58b0b42020-02-18 10:00:47 +020071
72::
73
74 {
75 "name": "virtualFirewall",
76 "description": "",
77 "data": [
78 {
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +010079 "file": "CBA.zip",
Samuli Silviusa58b0b42020-02-18 10:00:47 +020080 "type": "CONTROLLER_BLUEPRINT_ARCHIVE"
81 },
82 {
83 "file": "base_template.yaml",
84 "type": "HEAT",
85 "isBase": "true",
86 "data": [
87 {
88 "file": "base_template.env",
89 "type": "HEAT_ENV"
90 }
91 ]
92 },
93 {
94 "file": "base_template_cloudtech_k8s_charts.tgz",
Konrad Bańkacc67f632020-03-12 12:09:13 +010095 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
Samuli Silviusa58b0b42020-02-18 10:00:47 +020096 },
97 {
98 "file": "vfw.yaml",
99 "type": "HEAT",
100 "isBase": "false",
101 "data": [
102 {
103 "file": "vfw.env",
104 "type": "HEAT_ENV"
105 }
106 ]
107 },
108 {
109 "file": "vfw_cloudtech_k8s_charts.tgz",
Konrad Bańkacc67f632020-03-12 12:09:13 +0100110 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200111 },
112 {
113 "file": "vpkg.yaml",
114 "type": "HEAT",
115 "isBase": "false",
116 "data": [
117 {
118 "file": "vpkg.env",
119 "type": "HEAT_ENV"
120 }
121 ]
122 },
123 {
124 "file": "vpkg_cloudtech_k8s_charts.tgz",
Konrad Bańkacc67f632020-03-12 12:09:13 +0100125 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200126 },
127 {
128 "file": "vsn.yaml",
129 "type": "HEAT",
130 "isBase": "false",
131 "data": [
132 {
133 "file": "vsn.env",
134 "type": "HEAT_ENV"
135 }
136 ]
137 },
138 {
139 "file": "vsn_cloudtech_k8s_charts.tgz",
Konrad Bańkacc67f632020-03-12 12:09:13 +0100140 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200141 }
142 ]
143 }
144
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100145Produced **Native Helm** VSP onboarding package `Creating Onboarding Package`_ format has following MANIFEST file (package_native/MANIFEST.json). The Helm package is delivered as HELM package through SDC and SO. The *isBase* flag of HELM artifact is ignored by SDC but in the manifest one HELM or HEAT artifacts must be defined as isBase = true. If both HEAT and HELM are present in the same manifest file the base one must be always one of HELM artifacts. Moreover, the name of HELM type artifact must match the specified pattern: *helm_<some_name>* and the HEAT type artifacts, if present in the same manifest, cannot contain keyword *helm*. These limitations are a consequence of current limitations of the SDC onboarding and VSP validation engine and will be adresssed in the future releases.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200146
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100147::
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200148
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100149 {
150 "name": "virtualFirewall",
151 "description": "",
152 "data": [
153 {
154 "file": "CBA.zip",
155 "type": "CONTROLLER_BLUEPRINT_ARCHIVE"
156 },
157 {
158 "file": "helm_base_template.tgz",
159 "type": "HELM",
160 "isBase": "true"
161 },
162 {
163 "file": "helm_vfw.tgz",
164 "type": "HELM",
165 "isBase": "false"
166 },
167 {
168 "file": "helm_vpkg.tgz",
169 "type": "HELM",
170 "isBase": "false"
171 },
172 {
173 "file": "helm_vsn.tgz",
174 "type": "HELM",
175 "isBase": "false"
176 }
177 ]
178 }
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200179
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100180.. note:: CDS model (CBA package) is delivered as SDC supported own type CONTROLLER_BLUEPRINT_ARCHIVE but the current limitation of VSP onbarding forces to use the artifact name *CBA.zip* to automaticaly recognize CBA as a CONTROLLER_BLUEPRINT_ARCHIVE.
Konrad Bańkacc67f632020-03-12 12:09:13 +0100181
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200182CDS Model (CBA)
183...............
184
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100185Creating CDS model was the core of the use case work and also the most difficult and time consuming part. Current template used by use-case should be easily reusable for anyone. Once CDS GUI will be fully working, we think that CBA development should be much easier. For CBA structure reference, please visit it's documentation page `CDS Documentation`_.
Konrad Bańkac01b1fb2020-05-27 15:25:56 +0200186
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200187At first the target was to keep CDS model as close as possible to `vFW_CNF_CDS Model`_ use case model and only add smallest possible changes to enable also k8s usage. That is still the target but in practice model deviated from the original one already and time pressure pushed us to not care about sync. Basically the end result could be possible much streamlined if wanted to be smallest possible to working only for K8S based network functions.
188
deen1985589467c2020-12-28 10:40:03 +0100189As K8S application was split into multiple Helm packages to match vf-modules, CBA modeling follows the same and for each vf-module there's own template in CBA package. The list of artifact with the templates is different for **Dummy Heat** and **Native Helm** approach. The second one has artifact names starting with *helm_* prefix, in the same way like names of artifacts in the MANIFEST file of VSP differs. The **Dummy Heat** artifacts' list is following:
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200190
191::
192
193 "artifacts" : {
194 "base_template-template" : {
195 "type" : "artifact-template-velocity",
196 "file" : "Templates/base_template-template.vtl"
197 },
198 "base_template-mapping" : {
199 "type" : "artifact-mapping-resource",
200 "file" : "Templates/base_template-mapping.json"
201 },
202 "vpkg-template" : {
203 "type" : "artifact-template-velocity",
204 "file" : "Templates/vpkg-template.vtl"
205 },
206 "vpkg-mapping" : {
207 "type" : "artifact-mapping-resource",
208 "file" : "Templates/vpkg-mapping.json"
209 },
210 "vfw-template" : {
211 "type" : "artifact-template-velocity",
212 "file" : "Templates/vfw-template.vtl"
213 },
214 "vfw-mapping" : {
215 "type" : "artifact-mapping-resource",
216 "file" : "Templates/vfw-mapping.json"
217 },
218 "vnf-template" : {
219 "type" : "artifact-template-velocity",
220 "file" : "Templates/vnf-template.vtl"
221 },
222 "vnf-mapping" : {
223 "type" : "artifact-mapping-resource",
224 "file" : "Templates/vnf-mapping.json"
225 },
226 "vsn-template" : {
227 "type" : "artifact-template-velocity",
228 "file" : "Templates/vsn-template.vtl"
229 },
230 "vsn-mapping" : {
231 "type" : "artifact-mapping-resource",
232 "file" : "Templates/vsn-mapping.json"
233 }
234 }
235
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100236The **Native Helm** artifacts' list is following:
237
238::
239
240 "artifacts" : {
241 "helm_base_template-template" : {
242 "type" : "artifact-template-velocity",
243 "file" : "Templates/base_template-template.vtl"
244 },
245 "helm_base_template-mapping" : {
246 "type" : "artifact-mapping-resource",
247 "file" : "Templates/base_template-mapping.json"
248 },
249 "helm_vpkg-template" : {
250 "type" : "artifact-template-velocity",
251 "file" : "Templates/vpkg-template.vtl"
252 },
253 "helm_vpkg-mapping" : {
254 "type" : "artifact-mapping-resource",
255 "file" : "Templates/vpkg-mapping.json"
256 },
257 "helm_vfw-template" : {
258 "type" : "artifact-template-velocity",
259 "file" : "Templates/vfw-template.vtl"
260 },
261 "helm_vfw-mapping" : {
262 "type" : "artifact-mapping-resource",
263 "file" : "Templates/vfw-mapping.json"
264 },
265 "vnf-template" : {
266 "type" : "artifact-template-velocity",
267 "file" : "Templates/vnf-template.vtl"
268 },
269 "vnf-mapping" : {
270 "type" : "artifact-mapping-resource",
271 "file" : "Templates/vnf-mapping.json"
272 },
273 "helm_vsn-template" : {
274 "type" : "artifact-template-velocity",
275 "file" : "Templates/vsn-template.vtl"
276 },
277 "helm_vsn-mapping" : {
278 "type" : "artifact-mapping-resource",
279 "file" : "Templates/vsn-mapping.json"
280 }
281 }
282
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200283Only **resource-assignment** workflow of the CBA model is utilized in this demo. If final CBA model contains also **config-deploy** workflow it's there just to keep parity with original vFW CBA (for VMs). Same applies for the related template *Templates/nf-params-template.vtl* and it's mapping file.
284
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200285Another advance of the presented use case over solution presented in the Dublin release is possibility of the automatic generation and upload to multicloud/k8s plugin the RB profile content.
286RB profile can be used to enrich or to modify the content of the original helm package. Profile can be also used to add additional k8s helm templates for helm installation or can be used to
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100287modify existing k8s helm templates for each create CNF instance. It opens another level of CNF customization, much more than customization of helm package with override values.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200288
289::
290
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200291 ---
292 version: v1
293 type:
294 values: “override_values.yaml”
295 configresource:
296 - filepath: resources/deployment.yaml
297 chartpath: templates/deployment.yaml
298
299
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100300Above we have exemplary manifest file of the RB profile. Since Frankfurt *override_values.yaml* file does not need to be used as instantiation values are passed to the plugin over Instance API of k8s plugin. In the example, profile contains additional k8s helm template which will be added on demand to the helm package during its installation. In our case, depending on the SO instantiation request input parameters, vPGN helm package can be enriched with additional ssh service. Such service will be dynamically added to the profile by CDS and later on CDS will upload whole custom RB profile to multicloud/k8s plugin.
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200301
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100302In order to support generation and upload of profile, our vFW CBA model has enhanced **resource-assignment** workflow which contains additional step: **profile-upload**. It leverages dedicated functionality introduced in Guilin release that can be used to upload predefined profile or to generate and upload content of the profile with Velocity templating mechanism.
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200303
304::
305
306 "resource-assignment": {
307 "steps": {
308 "resource-assignment": {
309 "description": "Resource Assign Workflow",
310 "target": "resource-assignment",
311 "activities": [
312 {
313 "call_operation": "ResourceResolutionComponent.process"
314 }
315 ],
316 "on_success": [
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200317 "profile-upload"
318 ]
319 },
320 "profile-upload": {
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100321 "description": "Generate and upload K8s Profile",
322 "target": "k8s-profile-upload",
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200323 "activities": [
324 {
325 "call_operation": "ComponentScriptExecutor.process"
326 }
327 ]
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200328 }
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200329 },
330
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100331.. note:: In the Frankfurt reelase profile upload was implementes as a custom Kotlin script included into the CBA. It was responsible for upload of K8S profile into multicloud/k8s plugin. It is still a good example of the integration of Kotlin scripting into the CBA. For those interested in this functionaliy we recommend to look into the `Frankfurt CBA Definition`_ and `Frankfurt CBA Script`_.
332
deen1985589467c2020-12-28 10:40:03 +0100333In our example for vPKG helm package we may select *vfw-cnf-cds-vpkg-profile* profile that is included into CBA as a folder. Profile generation step uses Velocity templates processing embedded CDS functionality on its basis ssh port number (specified in the SO request as *vpg-management-port*).
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100334
335::
336
337 {
338 "name": "vpg-management-port",
339 "property": {
340 "description": "The number of node port for ssh service of vpg",
341 "type": "integer",
342 "default": "0"
343 },
344 "input-param": false,
345 "dictionary-name": "vpg-management-port",
346 "dictionary-source": "default",
347 "dependencies": []
348 }
349
350*vpg-management-port* can be included directly into the helm template and such template will be included into vPKG helm package in time of its instantiation.
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200351
352::
353
354 apiVersion: v1
355 kind: Service
356 metadata:
357 name: {{ .Values.vpg_name_0 }}-ssh-access
358 labels:
359 vnf-name: {{ .Values.vnf_name }}
360 vf-module-name: {{ .Values.vpg_name_0 }}
361 release: {{ .Release.Name }}
362 chart: {{ .Chart.Name }}
363 spec:
364 type: NodePort
365 ports:
366 - port: 22
367 nodePort: ${vpg-management-port}
368 selector:
369 vf-module-name: {{ .Values.vpg_name_0 }}
370 release: {{ .Release.Name }}
371 chart: {{ .Chart.Name }}
372
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100373
374The mechanism of profile generation and upload requires specific node teamplate in the CBA definition. In our case it comes with the declaration of two profiles: one static *vfw-cnf-cds-base-profile* in a form of an archive and the second complex *vfw-cnf-cds-vpkg-profile* in a form of a folder for processing and profile generation.
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200375
376::
377
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100378 "k8s-profile-upload": {
379 "type": "component-k8s-profile-upload",
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200380 "interfaces": {
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100381 "K8sProfileUploadComponent": {
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200382 "operations": {
383 "process": {
384 "inputs": {
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100385 "artifact-prefix-names": {
386 "get_input": "template-prefix"
387 },
388 "resource-assignment-map": {
389 "get_attribute": [
390 "resource-assignment",
391 "assignment-map"
392 ]
393 }
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200394 }
395 }
396 }
397 }
398 },
399 "artifacts": {
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100400 "vfw-cnf-cds-base-profile": {
401 "type": "artifact-k8sprofile-content",
402 "file": "Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz"
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200403 },
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100404 "vfw-cnf-cds-vpkg-profile": {
405 "type": "artifact-k8sprofile-content",
406 "file": "Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile"
407 },
408 "vfw-cnf-cds-vpkg-profile-mapping": {
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200409 "type": "artifact-mapping-resource",
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100410 "file": "Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json"
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200411 }
412 }
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200413 }
414
deen1985589467c2020-12-28 10:40:03 +0100415Artifact file determines a place of the static profile or the content of the complex profile. In the latter case we need a pair of profile folder and mappimng file with a declaration of the parameters that CDS needs to resolve first, before the Velocity templating is applied to the .vtl files present in the profile content. After Velocity templating the .vtl extensions will be dropped from the file names. The embedded mechanism will include in the profile only files present in the profile MANIFEST file that needs to contain the list of final names of the files to be included into the profile. The figure below shows the idea of profile templating.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200416
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100417.. figure:: files/vFW_CNF_CDS/profile-templating.png
418 :align: center
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200419
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100420 K8s Profile Templating
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200421
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100422SO requires for instantiation name of the profile in the parameter: *k8s-rb-profile-name*. The *component-k8s-profile-upload* that stands behind the profile uploading mechanism has input parameters that can be passed directly (checked in the first order) or can be taken from the *resource-assignment-map* parameter which can be a result of associated *component-resource-resolution* result, like in our case their values are resolved on vf-module level resource assignment. The *component-k8s-profile-upload* inputs are following:
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200423
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100424- k8s-rb-profile-name – (mandatory) the name of the profile under which it will be created in k8s plugin. Other parameters are required only when profile must be uploaded
425- k8s-rb-definition-name – the name under which RB definition was created - **VF Module Model Invariant ID** in ONAP
426- k8s-rb-definition-version – the version of created RB definition name - **VF Module Model Version ID** in ONAP
427- k8s-rb-profile-namespace – the k8s namespace name associated with profile being created
428- k8s-rb-profile-source – the source of profile content - name of the artifact of the profile
429- resource-assignment-map – result of the associated resource assignment step
430- artifact-prefix-names – (mandatory) the list of artifact prefixes like for resource-assigment step
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200431
deen1985589467c2020-12-28 10:40:03 +0100432In the SO request user can pass parameter of name *k8s-rb-profile-name* which in our case may have value: *vfw-cnf-cds-base-profile*, *vfw-cnf-cds-vpkg-profile* or *default*. The *default* profile doesn’t contain any content inside and allows instantiation of CNF without the need to define and upload any additional profiles. *vfw-cnf-cds-vpkg-profile* has been prepared to test instantiation of the second modified vFW CNF instance `Second Service Instance Instantiation`_.
Samuli Silvius7c41c162020-06-02 19:08:30 +0300433
Lukasz Rajewskidd9bf992020-12-30 18:43:39 +0100434K8splugin allows to specify override parameters (similar to --set behavior of helm client) to instantiated resource bundles. This allows for providing dynamic parameters to instantiated resources without the need to create new profiles for this purpose and should be used with *default* profile but may be used also with custom profiles. The overall flow of helm overrides parameters processing is visible on following figure. When *rb definition* (helm package) is being instantiated for specified *rb profile* K8splugin combines override values from the helm pakage, *rb profile* and from the instantiation request - in the respective order. It means that the some from instantiation request (SO request input or CDS resource assignement result) has a precedence over the value from the *rb profile* and value from the *rb profile* has a precedence over the helm package default override value. Similarly, profile can contain resource files that may extend or ammend the existing files for the original helm package content.
Samuli Silvius7c41c162020-06-02 19:08:30 +0300435
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100436.. figure:: files/vFW_CNF_CDS/helm-overrides.png
437 :align: center
Samuli Silvius7c41c162020-06-02 19:08:30 +0300438
Lukasz Rajewskidd9bf992020-12-30 18:43:39 +0100439 The overall flow of helm data processing
440
441Both profile content (4) like the instantiation request values (5) can be generated during the resource assignment process according to its definition for CBA associated with helm package. CBA may generate i.e. names, IP addresses, ports and can use this information to produce the *rb-profile* (3) content. Finally, all three sources of override values, temnplates and additional resources files are merged together (6) by K8splugin in the order exaplained before.
442
443.. figure:: files/vFW_CNF_CDS/helm-overrides-steps.png
444 :align: center
445
446 The steps of processing of helm data with help of CDS
Samuli Silvius7c41c162020-06-02 19:08:30 +0300447
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100448Finally, `Data Dictionary`_ is also included into demo git directory, re-modeling and making changes into model utilizing CDS model time / runtime is easier as used DD is also known.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200449
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100450.. note:: The CBA for this use case is already enriched and there is no need to perform enrichment process for it. It is also automatically uploaded into CDS in time of the model distribution from the SDC.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200451
452Instantiation Overview
mrichommee4643892020-11-30 18:31:29 +0100453----------------------
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200454
deen1985589467c2020-12-28 10:40:03 +0100455.. note:: Since Guilin release use case is equipped with automated method **<AUTOMATED>** with python scripts to replace Postman method **<MANUAL>** used in Frankfurt. Nevertheless, Postman collection is good to understand the entire process. If a user selects to follow Postman collection, then automation scripts **must not** be used. **For the entire process use only scripts or only Postman collection**. Both options are described in the further steps of this instruction.
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100456
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200457The figure below shows all the interactions that take place during vFW CNF instantiation. It's not describing flow of actions (ordered steps) but rather component dependencies.
458
459.. figure:: files/vFW_CNF_CDS/Instantiation_topology.png
460 :align: center
461
462 vFW CNF CDS Use Case Runtime interactions.
463
464PART 1 - ONAP Installation
mrichommee4643892020-11-30 18:31:29 +0100465~~~~~~~~~~~~~~~~~~~~~~~~~~
466
Samuli Silviusa58b0b42020-02-18 10:00:47 +02004671-1 Deployment components
mrichommee4643892020-11-30 18:31:29 +0100468.........................
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200469
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100470In order to run the vFW_CNF_CDS use case, we need ONAP Guilin Release (or later) with at least following components:
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200471
472======================================================= ===========
473ONAP Component name Describtion
474------------------------------------------------------- -----------
475AAI Required for Inventory Cloud Owner, Customer, Owning Entity, Service, Generic VNF, VF Module
476SDC VSP, VF and Service Modeling of the CNF
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200477DMAAP Distribution of the onboarding package including CBA to all ONAP components
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200478SO Requires for Macro Orchestration using the generic building blocks
479CDS Resolution of cloud parameters including Helm override parameters for the CNF. Creation of the multicloud/k8s profile for CNF instantion.
480SDNC (needs to include netbox and Naming Generation mS) Provides GENERIC-RESOURCE-API for cloud Instantiation orchestration via CDS.
481Policy Used to Store Naming Policy
482AAF Used for Authentication and Authorization of requests
483Portal Required to access SDC.
484MSB Exposes multicloud interfaces used by SO.
Konrad Bańkacc67f632020-03-12 12:09:13 +0100485Multicloud K8S plugin part used to pass SO instantiation requests to external Kubernetes cloud region.
Konrad Bańkac01b1fb2020-05-27 15:25:56 +0200486Contrib Chart containing multiple external components. Out of those, we only use Netbox utility in this use-case for IPAM
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200487Robot Optional. Can be used for running automated tasks, like provisioning cloud customer, cloud region, service subscription, etc ..
488Shared Cassandra DB Used as a shared storage for ONAP components that rely on Cassandra DB, like AAI
489Shared Maria DB Used as a shared storage for ONAP components that rely on Maria DB, like SDNC, and SO
490======================================================= ===========
491
4921-2 Deployment
mrichommee4643892020-11-30 18:31:29 +0100493..............
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200494
495In order to deploy such an instance, follow the `ONAP Deployment Guide`_
496
497As we can see from the guide, we can use an override file that helps us customize our ONAP deployment, without modifying the OOM Folder, so you can download this override file here, that includes the necessary components mentioned above.
498
499**override.yaml** file where enabled: true is set for each component needed in demo (by default all components are disabled).
500
501::
502
503 aai:
504 enabled: true
505 aaf:
506 enabled: true
507 cassandra:
508 enabled: true
509 cds:
510 enabled: true
511 contrib:
512 enabled: true
513 dmaap:
514 enabled: true
515 mariadb-galera:
516 enabled: true
517 msb:
518 enabled: true
519 multicloud:
520 enabled: true
521 policy:
522 enabled: true
523 portal:
524 enabled: true
525 robot:
526 enabled: true
527 sdc:
528 enabled: true
529 sdnc:
530 enabled: true
531 so:
532 enabled: true
533
534Then deploy ONAP with Helm with your override file.
535
536::
537
538 helm deploy onap local/onap --namespace onap -f ~/override.yaml
539
540In case redeployment needed `Helm Healer`_ could be a faster and convenient way to redeploy.
541
542::
543
544 helm-healer.sh -n onap -f ~/override.yaml -s /dockerdata-nfs --delete-all
545
546Or redeploy (clean re-deploy also data removed) just wanted components (Helm releases), cds in this example.
547
548::
549
550 helm-healer.sh -f ~/override.yaml -s /dockerdata-nfs/ -n onap -c onap-cds
551
552There are many instructions in ONAP wiki how to follow your deployment status and does it succeeded or not, mostly using Robot Health checks. One way we used is to skip the outermost Robot wrapper and use directly ete-k8s.sh to able to select checked components easily. Script is found from OOM git repository *oom/kubernetes/robot/ete-k8s.sh*.
553
554::
555
Konrad Bańkacc67f632020-03-12 12:09:13 +0100556 {
557 failed=
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200558 for comp in {aaf,aai,dmaap,msb,multicloud,policy,portal,sdc,sdnc,so}; do
559 if ! ./ete-k8s.sh onap health-$comp; then
560 failed=$failed,$comp
561 fi
562 done
563 if [ -n "$failed" ]; then
564 echo "These components failed: $failed"
565 false
566 else
567 echo "Healthcheck successful"
568 fi
Konrad Bańkacc67f632020-03-12 12:09:13 +0100569 }
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200570
571And check status of pods, deployments, jobs etc.
572
573::
574
575 kubectl -n onap get pods | grep -vie 'completed' -e 'running'
576 kubectl -n onap get deploy,sts,jobs
577
578
5791-3 Post Deployment
mrichommee4643892020-11-30 18:31:29 +0100580...................
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200581
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100582After completing the first part above, we should have a functional ONAP deployment for the Guilin Release.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200583
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100584We will need to apply a few modifications to the deployed ONAP Guilin instance in order to run the use case.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200585
Konrad Bańkacc67f632020-03-12 12:09:13 +0100586Retrieving logins and passwords of ONAP components
mrichommee4643892020-11-30 18:31:29 +0100587++++++++++++++++++++++++++++++++++++++++++++++++++
Konrad Bańkacc67f632020-03-12 12:09:13 +0100588
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200589Since Frankfurt release hardcoded passwords were mostly removed and it is possible to configure passwords of ONAP components in time of their installation. In order to retrieve these passwords with associated logins it is required to get them with kubectl. Below is the procedure on mariadb-galera DB component example.
Konrad Bańkacc67f632020-03-12 12:09:13 +0100590
591::
592
Konrad Bańka38af9cf2020-06-01 09:36:09 +0200593 kubectl get secret `kubectl get secrets | grep mariadb-galera-db-root-password | awk '{print $1}'` -o jsonpath="{.data.login}" | base64 --decode
594 kubectl get secret `kubectl get secrets | grep mariadb-galera-db-root-password | awk '{print $1}'` -o jsonpath="{.data.password}" | base64 --decode
Konrad Bańkacc67f632020-03-12 12:09:13 +0100595
596In this case login is empty as the secret is dedicated to root user.
597
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100598
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200599Postman collection setup
mrichommee4643892020-11-30 18:31:29 +0100600++++++++++++++++++++++++
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200601
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100602In this demo we have on purpose created all manual ONAP preparation steps (which in real life are automated) by using Postman so it will be clear what exactly is needed. Some of the steps like AAI population is automated by Robot scripts in other ONAP demos (**./demo-k8s.sh onap init**) and Robot script could be used for many parts also in this demo.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200603
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200604Postman collection is used also to trigger instantiation using SO APIs.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200605
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200606Following steps are needed to setup Postman:
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200607
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200608- Import this Postman collection zip
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200609
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200610 :download:`Postman collection <files/vFW_CNF_CDS/postman.zip>`
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200611
Konrad Bańkac01b1fb2020-05-27 15:25:56 +0200612- Extract the zip and import Postman collection into Postman. Environment file is provided for reference, it's better to create own environment on your own providing variables as listed in next chapter.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200613 - `vFW_CNF_CDS.postman_collection.json`
614 - `vFW_CNF_CDS.postman_environment.json`
615
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200616- For use case debugging purposes to get Kubernetes cluster external access to SO CatalogDB (GET operations only), modify SO CatalogDB service to NodePort instead of ClusterIP. You may also create separate own NodePort if you wish, but here we have just edited directly the service with kubectl.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200617
618::
619
620 kubectl -n onap edit svc so-catalog-db-adapter
621 - .spec.type: ClusterIP
622 + .spec.type: NodePort
623 + .spec.ports[0].nodePort: 30120
624
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200625.. note:: The port number 30120 is used in included Postman collection
626
Konrad Bańkac01b1fb2020-05-27 15:25:56 +0200627- You may also want to inspect after SDC distribution if CBA has been correctly delivered to CDS. In order to do it, there are created relevant calls later described in doc, however CDS since Frankfurt doesn't expose blueprints-processor's service as NodePort. This is OPTIONAL but if you'd like to use these calls later, you need to expose service in similar way as so-catalog-db-adapter above:
628
629::
630
631 kubectl edit -n onap svc cds-blueprints-processor-http
632 - .spec.type: ClusterIP
633 + .spec.type: NodePort
634 + .spec.ports[0].nodePort: 30499
635
636.. note:: The port number 30499 is used in included Postman collection
637
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200638**Postman variables:**
639
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200640Most of the Postman variables are automated by Postman scripts and environment file provided, but there are few mandatory variables to fill by user.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200641
Konrad Bańkac01b1fb2020-05-27 15:25:56 +0200642===================== ===================
643Variable Description
644--------------------- -------------------
645k8s ONAP Kubernetes host
646sdnc_port port of sdnc service for accessing MDSAL
647service-name name of service as defined in SDC
648service-version version of service defined in SDC (if service wasn't updated, it should be set to "1.0")
649service-instance-name name of instantiated service (if ending with -{num}, will be autoincremented for each instantiation request)
650===================== ===================
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200651
652You can get the sdnc_port value with
653
654::
655
656 kubectl -n onap get svc sdnc -o json | jq '.spec.ports[]|select(.port==8282).nodePort'
657
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100658Automation Environment Setup
659............................
660
661Whole content of this use case is stored into single git repository and it contains both the required onboarding information as well as automation scripts for onboarding and instantiation of the use case.
662
663::
664
665 git clone --single-branch --branch guilin "https://gerrit.onap.org/r/demo"
666 cd demo/heat/vFW_CNF_CDS/templates
667
668In order to prepare environment for onboarding and instantiation of the use case make sure you have *git*, *make*, *helm* and *pipenv* applications installed.
669
670The automation scripts are based on `Python SDK`_ and are adopted to automate process of service onboarding, instantiation, deletion and cloud region registration. To configure them for further use:
671
672::
673
674 cd demo/heat/vFW_CNF_CDS/automation
675
6761. Install required packages with
677::
678
679 pipenv pipenv install
680
6812. Run virtual python environment
682::
683
684 pipenv shell --fancy
685
6863. Add kubeconfig files, one for ONAP cluster, and one for k8s cluster that will host vFW
687
688.. note:: Both files can be configured after creation of k8s cluster for vFW instance `2-1 Installation of Managed Kubernetes`_. Make sure that they have configured external IP address properly. If any cluster uses self signed certificates set also *insecure-skip-tls-verify* flag in the config file.
689
690- artifacts/cluster_kubeconfig - IP address must be reachable by ONAP pods, especially *mutlicloud-k8s* pod
691
692- artifacts/onap_kubeconfig - IP address must be reachable by automation scripts
693
6944. Modify config.py file
695
696- NATIVE - when enabled **Native Helm** path will be used, otherwise **Dummy Heat** path will be used
697- CLOUD_REGION - name of your k8s cluster from ONAP perspective
698- GLOBAL_CUSTOMER_ID - identifier of customer in ONAP
699- VENDOR - name of the Vendor in ONAP
700- SERVICENAME - **Name of your service model in SDC**
701- CUSTOMER_RESOURCE_DEFINITIONS - add list of CRDs to be installed on non KUD k8s cluster - should be used ony to use some non-KUD cluster like i.e. ONAP one to test instantiation of Helm package. For KUD should be empty list
702
703.. note:: For automation script it is necessary to modify only NATIVE and SERVICENAME constants. Other constants may be modified if needed.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200704
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200705AAI
706...
707
708Some basic entries are needed in ONAP AAI. These entries are needed ones per onap installation and do not need to be repeated when running multiple demos based on same definitions.
709
710Create all these entries into AAI in this order. Postman collection provided in this demo can be used for creating each entry.
711
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100712**<MANUAL>**
713::
714
715 Postman -> Initial ONAP setup -> Create
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200716
717- Create Customer
718- Create Owning-entity
719- Create Platform
720- Create Project
721- Create Line Of Business
722
Konrad Bańkac01b1fb2020-05-27 15:25:56 +0200723Corresponding GET operations in "Check" folder in Postman can be used to verify entries created. Postman collection also includes some code that tests/verifies some basic issues e.g. gives error if entry already exists.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200724
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100725**<AUTOMATED>**
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200726
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100727This step is performed jointly with onboarding step `3-1 Onboarding`_
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200728
729Naming Policy
mrichommee4643892020-11-30 18:31:29 +0100730+++++++++++++
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200731
732Naming policy is needed to generate unique names for all instance time resources that are wanted to be modeled in the way naming policy is used. Those are normally VNF, VNFC and VF-module names, network names etc. Naming is general ONAP feature and not limited to this use case.
733
Konrad Bańkac01b1fb2020-05-27 15:25:56 +0200734This usecase leverages default ONAP naming policy - "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP".
735To check that the naming policy is created and pushed OK, we can run the command below from inside any ONAP pod.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200736
Konrad Bańkac01b1fb2020-05-27 15:25:56 +0200737::
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200738
Konrad Bańkac01b1fb2020-05-27 15:25:56 +0200739 curl --silent -k --user 'healthcheck:zb!XztG34' -X GET "https://policy-api:6969/policy/api/v1/policytypes/onap.policies.Naming/versions/1.0.0/policies/SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP/versions/1.0.0"
740
741.. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200742
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200743PART 2 - Installation of managed Kubernetes cluster
mrichommee4643892020-11-30 18:31:29 +0100744~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200745
746In this demo the target cloud region is a Kubernetes cluster of your choice basically just like with Openstack. ONAP platform is a bit too much hard wired to Openstack and it's visible in many demos.
747
7482-1 Installation of Managed Kubernetes
mrichommee4643892020-11-30 18:31:29 +0100749......................................
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200750
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100751In this demo we use Kubernetes deployment used by ONAP multicloud/k8s team to test their plugin features see `KUD github`_. There's also some outdated instructions in ONAP wiki `KUD in Wiki`_.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200752
753KUD deployment is fully automated and also used in ONAP's CI/CD to automatically verify all `Multicloud k8s gerrit`_ commits (see `KUD Jenkins ci/cd verification`_) and that's quite good (and rare) level of automated integration testing in ONAP. KUD deployemnt is used as it's installation is automated and it also includes bunch of Kubernetes plugins used to tests various k8s plugin features. In addition to deployement, KUD repository also contains test scripts to automatically test multicloud/k8s plugin features. Those scripts are run in CI/CD.
754
755See `KUD subproject in github`_ for a list of additional plugins this Kubernetes deployment has. In this demo the tested CNF is dependent on following plugins:
756
757- ovn4nfv
758- Multus
759- Virtlet
760
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100761Follow instructions in `KUD github`_ and install target Kubernetes cluster in your favorite machine(s), simplest being just one machine. Your cluster nodes(s) needs to be accessible from ONAP Kuberenetes nodes. Make sure your installed *pip* is of **version < 21.0**. Version 21 do not support python 2.7 that is used in *aio.sh* script. Also to avoid performance problems of your k8s cluster make sure you install only necessary plugins and before running *aio.sh* script execute following command
762::
763
764 export KUD_ADDONS="virtlet ovn4nfv"
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200765
7662-2 Cloud Registration
mrichommee4643892020-11-30 18:31:29 +0100767......................
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200768
769Managed Kubernetes cluster is registered here into ONAP as one cloud region. This obviously is done just one time for this particular cloud. Cloud registration information is kept in AAI.
770
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100771**<MANUAL>**
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200772
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100773Postman collection have folder/entry for each step. Execute in this order.
774::
775
776 Postman -> K8s Cloud Region Registration -> Create
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200777
778- Create Complex
779- Create Cloud Region
780- Create Complex-Cloud Region Relationship
781- Create Service
782- Create Service Subscription
783- Create Cloud Tenant
784- Create Availability Zone
Konrad Bańkac01b1fb2020-05-27 15:25:56 +0200785- Upload Connectivity Info
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200786
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100787.. note:: For "Upload Connectivity Info" call you need to provide kubeconfig file of existing KUD cluster. You can find that kubeconfig on deployed KUD in the directory `~/.kube/config` and this file can be easily copied e.g. via SCP. Please ensure that kubeconfig contains external IP of K8s cluster in kubeconfig and correct it, if it's not.
Konrad Bańkacc67f632020-03-12 12:09:13 +0100788
789SO database needs to be (manually) modified for SO to know that this particular cloud region is to be handled by multicloud. Values we insert needs to obviously match to the ones we populated into AAI.
790
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200791.. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
792
Konrad Bańkacc67f632020-03-12 12:09:13 +0100793::
794
795 kubectl -n onap exec onap-mariadb-galera-0 -it -- mysql -uroot -psecretpassword -D catalogdb
796 select * from cloud_sites;
797 insert into cloud_sites(ID, REGION_ID, IDENTITY_SERVICE_ID, CLOUD_VERSION, CLLI, ORCHESTRATOR) values("k8sregionfour", "k8sregionfour", "DEFAULT_KEYSTONE", "2.5", "clli2", "multicloud");
798 select * from cloud_sites;
799 exit
800
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100801.. note:: The configuration of the new k8s cloud site is documented also here `K8s cloud site config`_
802
803**<AUTOMATED>**
804
805Please copy the kubeconfig file of existing KUD cluster to automation/artifacts/cluster_kubeconfig location `Automation Environment Setup`_ - step **3**. You can find that kubeconfig on deployed KUD in the directory `~/.kube/config` and this file can be easily copied e.g. via SCP. Please ensure that kubeconfig contains external IP of K8s cluster in kubeconfig and correct it, if it's not.
806
807::
808
809 python create_k8s_region.py
810
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200811PART 3 - Execution of the Use Case
mrichommee4643892020-11-30 18:31:29 +0100812~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200813
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100814This part contains all the steps to run the use case by using ONAP GUIs, Postman or Python automation scripts.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200815
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100816Following pictures describe the overall sequential flow of the use case in two scenarios: **Dummy Heat** path (with OpenStack adapter) and **Native Helm** path (with CNF Adapter)
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200817
Lukasz Rajewskidd9bf992020-12-30 18:43:39 +0100818Dummy Heat CNF Orchestration
819............................
820
821This orchestration method stands on the grounds of Heat template orchestration mechanisms. In SDC onboarding package needs to contains simple Heat templates that are associated with additional Cloud artifacts. SDC distributes Heat templates to SO and Helm packages to K8sPlugin directly. SO orchestrates the Heat templates without any knowledge about their existence, however the OpenStack adater in SO understands k8s region type for which communication over MSB/Mutlicloud is provided - it handles interaction with K8sPlugin for CNF instantiation.
822
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100823.. figure:: files/vFW_CNF_CDS/Dummy_Heat_Flow.png
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200824 :align: center
825
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100826 vFW CNF CDS Use Case sequence flow for *Dummy Heat* (Frankfurt) path.
827
Lukasz Rajewskidd9bf992020-12-30 18:43:39 +0100828Native Helm CNF Orchestration
829.............................
830
831Introduced in the Guilin release CNF orchestration method brings native distribution of Helm packages from SDC and native orchestration of CNFs (Helm packages) with SO. SO leverages CNF adapter to interact with K8sPlugin that takes resposnibility for the communication with k8s clusters. Heat templates are not required in the SDC onboarding package and thanks to the fact that SO knows about Helm package orchestration future synchronization of data between k8s clusters and AAI is possible.
832
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100833.. figure:: files/vFW_CNF_CDS/Native_Helm_Flow.png
834 :align: center
835
836 vFW CNF CDS Use Case sequence flow for *Native Helm* (Guilin) path.
837
Lukasz Rajewskidd9bf992020-12-30 18:43:39 +0100838.. warning:: The **Native Helm** path has identified defects in the instantiation process and requires SO images of version 1.7.11 for successfull instantiation of the CNF. Please monitor `SO-3403`_ and `SO-3404`_ tickets to make sure that necessary fixes have been delivered. SO 1.7.11 images were released Dec 24th 2020. Make sure to use them in Your ONAP/Guilin installation.
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100839
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200840
8413-1 Onboarding
mrichommee4643892020-11-30 18:31:29 +0100842..............
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200843
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100844.. note:: Make sure you have performed `Automation Environment Setup`_ steps before following actions here.
845
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200846Creating Onboarding Package
mrichommee4643892020-11-30 18:31:29 +0100847+++++++++++++++++++++++++++
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200848
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100849Content of the onboarding package can be created with provided Makefile in the *template* folder.
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200850
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100851Complete content of both Onboarding Packages for **Dummy Heat** and **Native Helm** is packaged to the following VSP onboarding package files:
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +0200852
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100853- **Dummy Heat** path: **vfw_k8s_demo.zip**
854
855- **Native Helm** path: **native_vfw_k8s_demo.zip**
856
857.. note:: Procedure requires *make* and *helm* applications installed
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200858
859::
860
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100861 git clone --single-branch --branch guilin "https://gerrit.onap.org/r/demo"
862 cd demo/heat/vFW_CNF_CDS/templates
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200863 make
864
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100865The result of make operation execution is following:
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200866::
867
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100868 make clean
869 make[1]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates'
870 rm -rf package_dummy/
871 rm -rf package_native/
872 rm -rf cba_dummy
873 rm -f vfw_k8s_demo.zip
874 rm -f native_vfw_k8s_demo.zip
875 make[1]: Leaving directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates'
876 make all
877 make[1]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates'
878 mkdir package_dummy/
879 mkdir package_native/
880 make -C helm
881 make[2]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm'
882 rm -f base_template-*.tgz
883 rm -f helm_base_template.tgz
884 rm -f base_template_cloudtech_k8s_charts.tgz
885 helm package base_template
886 Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/base_template-0.2.0.tgz
887 mv base_template-*.tgz helm_base_template.tgz
888 cp helm_base_template.tgz base_template_cloudtech_k8s_charts.tgz
889 rm -f vpkg-*.tgz
890 rm -f helm_vpkg.tgz
891 rm -f vpkg_cloudtech_k8s_charts.tgz
892 helm package vpkg
893 Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/vpkg-0.2.0.tgz
894 mv vpkg-*.tgz helm_vpkg.tgz
895 cp helm_vpkg.tgz vpkg_cloudtech_k8s_charts.tgz
896 rm -f vfw-*.tgz
897 rm -f helm_vfw.tgz
898 rm -f vfw_cloudtech_k8s_charts.tgz
899 helm package vfw
900 Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/vfw-0.2.0.tgz
901 mv vfw-*.tgz helm_vfw.tgz
902 cp helm_vfw.tgz vfw_cloudtech_k8s_charts.tgz
903 rm -f vsn-*.tgz
904 rm -f helm_vsn.tgz
905 rm -f vsn_cloudtech_k8s_charts.tgz
906 helm package vsn
907 Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/vsn-0.2.0.tgz
908 mv vsn-*.tgz helm_vsn.tgz
909 cp helm_vsn.tgz vsn_cloudtech_k8s_charts.tgz
910 make[2]: Leaving directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm'
911 mv helm/helm_*.tgz package_native/
912 mv helm/*.tgz package_dummy/
913 cp base_dummy/* package_dummy/
914 cp base_native/* package_native/
915 cp -r cba cba_dummy
916 sed -i 's/"helm_/"/g' cba_dummy/Definitions/vFW_CNF_CDS.json
917 cd cba_dummy/ && zip -r CBA.zip . -x pom.xml .idea/\* target/\*
918 adding: Definitions/ (stored 0%)
919 adding: Definitions/artifact_types.json (deflated 69%)
920 adding: Definitions/data_types.json (deflated 88%)
921 adding: Definitions/node_types.json (deflated 90%)
922 adding: Definitions/policy_types.json (stored 0%)
923 adding: Definitions/relationship_types.json (stored 0%)
924 adding: Definitions/resources_definition_types.json (deflated 94%)
925 adding: Definitions/vFW_CNF_CDS.json (deflated 87%)
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200926 adding: Scripts/ (stored 0%)
927 adding: Scripts/kotlin/ (stored 0%)
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200928 adding: Scripts/kotlin/README.md (stored 0%)
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100929 adding: Templates/ (stored 0%)
930 adding: Templates/base_template-mapping.json (deflated 89%)
931 adding: Templates/base_template-template.vtl (deflated 87%)
932 adding: Templates/k8s-profiles/ (stored 0%)
933 adding: Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz (stored 0%)
934 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ (stored 0%)
935 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/manifest.yaml (deflated 35%)
936 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/override_values.yaml (stored 0%)
937 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json (deflated 51%)
938 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-template.yaml.vtl (deflated 56%)
939 adding: Templates/nf-params-mapping.json (deflated 88%)
940 adding: Templates/nf-params-template.vtl (deflated 44%)
941 adding: Templates/vfw-mapping.json (deflated 89%)
942 adding: Templates/vfw-template.vtl (deflated 87%)
943 adding: Templates/vnf-mapping.json (deflated 89%)
944 adding: Templates/vnf-template.vtl (deflated 93%)
945 adding: Templates/vpkg-mapping.json (deflated 89%)
946 adding: Templates/vpkg-template.vtl (deflated 87%)
947 adding: Templates/vsn-mapping.json (deflated 89%)
948 adding: Templates/vsn-template.vtl (deflated 87%)
949 adding: TOSCA-Metadata/ (stored 0%)
950 adding: TOSCA-Metadata/TOSCA.meta (deflated 37%)
951 cd cba/ && zip -r CBA.zip . -x pom.xml .idea/\* target/\*
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200952 adding: Definitions/ (stored 0%)
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100953 adding: Definitions/artifact_types.json (deflated 69%)
954 adding: Definitions/data_types.json (deflated 88%)
955 adding: Definitions/node_types.json (deflated 90%)
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200956 adding: Definitions/policy_types.json (stored 0%)
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200957 adding: Definitions/relationship_types.json (stored 0%)
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100958 adding: Definitions/resources_definition_types.json (deflated 94%)
959 adding: Definitions/vFW_CNF_CDS.json (deflated 87%)
960 adding: Scripts/ (stored 0%)
961 adding: Scripts/kotlin/ (stored 0%)
962 adding: Scripts/kotlin/README.md (stored 0%)
963 adding: Templates/ (stored 0%)
964 adding: Templates/base_template-mapping.json (deflated 89%)
965 adding: Templates/base_template-template.vtl (deflated 87%)
966 adding: Templates/k8s-profiles/ (stored 0%)
967 adding: Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz (stored 0%)
968 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ (stored 0%)
969 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/manifest.yaml (deflated 35%)
970 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/override_values.yaml (stored 0%)
971 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json (deflated 51%)
972 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-template.yaml.vtl (deflated 56%)
973 adding: Templates/nf-params-mapping.json (deflated 88%)
974 adding: Templates/nf-params-template.vtl (deflated 44%)
975 adding: Templates/vfw-mapping.json (deflated 89%)
976 adding: Templates/vfw-template.vtl (deflated 87%)
977 adding: Templates/vnf-mapping.json (deflated 89%)
978 adding: Templates/vnf-template.vtl (deflated 93%)
979 adding: Templates/vpkg-mapping.json (deflated 89%)
980 adding: Templates/vpkg-template.vtl (deflated 87%)
981 adding: Templates/vsn-mapping.json (deflated 89%)
982 adding: Templates/vsn-template.vtl (deflated 87%)
983 adding: TOSCA-Metadata/ (stored 0%)
984 adding: TOSCA-Metadata/TOSCA.meta (deflated 37%)
985 mv cba/CBA.zip package_native/
986 mv cba_dummy/CBA.zip package_dummy/
987 cd package_dummy/ && zip -r vfw_k8s_demo.zip .
988 adding: base_template.env (deflated 22%)
989 adding: base_template.yaml (deflated 59%)
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200990 adding: base_template_cloudtech_k8s_charts.tgz (stored 0%)
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100991 adding: CBA.zip (stored 0%)
992 adding: MANIFEST.json (deflated 84%)
993 adding: vfw.env (deflated 23%)
994 adding: vfw.yaml (deflated 60%)
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200995 adding: vfw_cloudtech_k8s_charts.tgz (stored 0%)
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100996 adding: vpkg.env (deflated 13%)
997 adding: vpkg.yaml (deflated 59%)
Samuli Silviusa58b0b42020-02-18 10:00:47 +0200998 adding: vpkg_cloudtech_k8s_charts.tgz (stored 0%)
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +0100999 adding: vsn.env (deflated 15%)
1000 adding: vsn.yaml (deflated 59%)
1001 adding: vsn_cloudtech_k8s_charts.tgz (stored 0%)
1002 cd package_native/ && zip -r native_vfw_k8s_demo.zip .
1003 adding: CBA.zip (stored 0%)
1004 adding: helm_base_template.tgz (stored 0%)
1005 adding: helm_vfw.tgz (stored 0%)
1006 adding: helm_vpkg.tgz (stored 0%)
1007 adding: helm_vsn.tgz (stored 0%)
1008 adding: MANIFEST.json (deflated 71%)
1009 mv package_dummy/vfw_k8s_demo.zip .
1010 mv package_native/native_vfw_k8s_demo.zip .
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001011 $
1012
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001013Import this package into SDC and follow onboarding steps.
1014
1015Service Creation with SDC
mrichommee4643892020-11-30 18:31:29 +01001016+++++++++++++++++++++++++
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001017
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001018**<MANUAL>**
1019
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001020Service Creation in SDC is composed of the same steps that are performed by most other use-cases. For reference, you can relate to `vLB use-case`_
1021
1022Onboard VSP
mrichomme0794e672020-06-09 15:37:37 +02001023
1024- Remember during VSP onboard to choose "Network Package" Onboarding procedure
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001025
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001026Create VF and Service
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001027Service -> Properties Assignment -> Choose VF (at right box):
mrichomme0794e672020-06-09 15:37:37 +02001028
1029- skip_post_instantiation_configuration - True
1030- sdnc_artifact_name - vnf
1031- sdnc_model_name - vFW_CNF_CDS
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001032- sdnc_model_version - 7.0.0
1033
1034**<AUTOMATED>**
1035.. note:: The onboarding packages for **Dummy Heat** and **Native Helm** path contain different CBA packages but with the same version and number. In consequence, when one VSP is distributed it replaces the CBA package of the other one and you can instantiate service only for the vFW CNF service service model distributed as a last one. If you want to instantiate vFW CNF service, make sure you have fresh distribution of vFW CNF service model.
1036
1037::
1038
1039 python onboarding.py
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001040
1041Distribution Of Service
mrichommee4643892020-11-30 18:31:29 +01001042+++++++++++++++++++++++
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001043
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001044**<MANUAL>**
1045
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001046Distribute service.
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001047
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001048Verify in SDC UI if distribution was successful. In case of any errors (sometimes SO fails on accepting CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT), try redistribution. You can also verify distribution for few components manually:
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001049
1050- SDC:
1051
1052 SDC Catalog database should have our service now defined.
1053
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001054 ::
1055
1056 Postman -> LCM -> [SDC] Catalog Service
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001057
1058 ::
1059
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001060 {
1061 "uuid": "64dd38f3-2307-4e0a-bc98-5c2cbfb260b6",
1062 "invariantUUID": "cd1a5c2d-2d4e-4d62-ac10-a5fe05e32a22",
1063 "name": "vfw_cnf_cds_svc",
1064 "version": "1.0",
1065 "toscaModelURL": "/sdc/v1/catalog/services/64dd38f3-2307-4e0a-bc98-5c2cbfb260b6/toscaModel",
1066 "category": "Network L4+",
1067 "lifecycleState": "CERTIFIED",
1068 "lastUpdaterUserId": "cs0008",
1069 "distributionStatus": "DISTRIBUTED"
1070 }
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001071
1072 Listing should contain entry with our service name **vfw_cnf_cds_svc**.
1073
1074.. note:: Note that it's an example name, it depends on how your model is named during Service design in SDC and must be kept in sync with Postman variables.
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001075
1076- SO:
1077
1078 SO Catalog database should have our service NFs defined now.
1079
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001080 ::
1081
1082 Postman -> LCM -> [SO] Catalog DB Service xNFs
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001083
1084 ::
1085
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001086 {
1087 "serviceVnfs": [
Samuli Silvius7c41c162020-06-02 19:08:30 +03001088 {
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001089 "modelInfo": {
1090 "modelName": "vfw_cnf_cds_vsp",
1091 "modelUuid": "70edaca8-8c79-468a-aa76-8224cfe686d0",
1092 "modelInvariantUuid": "7901fc89-a94d-434a-8454-1e27b99dc0e2",
1093 "modelVersion": "1.0",
1094 "modelCustomizationUuid": "86dc8af4-aa17-4fc7-9b20-f12160d99718",
1095 "modelInstanceName": "vfw_cnf_cds_vsp 0"
1096 },
1097 "toscaNodeType": "org.openecomp.resource.vf.VfwCnfCdsVsp",
1098 "nfFunction": null,
1099 "nfType": null,
1100 "nfRole": null,
1101 "nfNamingCode": null,
1102 "multiStageDesign": "false",
1103 "vnfcInstGroupOrder": null,
1104 "resourceInput": "TBD",
1105 "vfModules": [
Samuli Silvius7c41c162020-06-02 19:08:30 +03001106 {
1107 "modelInfo": {
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001108 "modelName": "VfwCnfCdsVsp..base_template..module-0",
1109 "modelUuid": "274f4bc9-7679-4767-b34d-1df51cdf2496",
1110 "modelInvariantUuid": "52842255-b7be-4a1c-ab3b-2bd3bd4a5423",
1111 "modelVersion": "1",
1112 "modelCustomizationUuid": "b27fad11-44da-4840-9256-7ed8a32fbe3e"
Samuli Silvius7c41c162020-06-02 19:08:30 +03001113 },
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001114 "isBase": true,
1115 "vfModuleLabel": "base_template",
1116 "initialCount": 1,
1117 "hasVolumeGroup": false
1118 },
1119 {
1120 "modelInfo": {
1121 "modelName": "VfwCnfCdsVsp..vsn..module-1",
1122 "modelUuid": "0cbf558f-5a96-4555-b476-7df8163521aa",
1123 "modelInvariantUuid": "36f25e1b-199b-4de2-b656-c870d341cf0e",
1124 "modelVersion": "1",
1125 "modelCustomizationUuid": "4cac0584-c0d6-42a7-bdb3-29162792e07f"
1126 },
1127 "isBase": false,
1128 "vfModuleLabel": "vsn",
1129 "initialCount": 0,
1130 "hasVolumeGroup": false
1131 },
1132 {
1133 "modelInfo": {
1134 "modelName": "VfwCnfCdsVsp..vpkg..module-2",
1135 "modelUuid": "011b5f61-6524-4789-bd9a-44cfbf321463",
1136 "modelInvariantUuid": "4e2b9975-5214-48b8-861a-5701c09eedfa",
1137 "modelVersion": "1",
1138 "modelCustomizationUuid": "4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb"
1139 },
1140 "isBase": false,
1141 "vfModuleLabel": "vpkg",
1142 "initialCount": 0,
1143 "hasVolumeGroup": false
1144 },
1145 {
1146 "modelInfo": {
1147 "modelName": "VfwCnfCdsVsp..vfw..module-3",
1148 "modelUuid": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f",
1149 "modelInvariantUuid": "9ffda670-3d77-4f6c-a4ad-fb7a09f19817",
1150 "modelVersion": "1",
1151 "modelCustomizationUuid": "1e123e43-ba40-4c93-90d7-b9f27407ec03"
1152 },
1153 "isBase": false,
1154 "vfModuleLabel": "vfw",
1155 "initialCount": 0,
1156 "hasVolumeGroup": false
Samuli Silvius7c41c162020-06-02 19:08:30 +03001157 }
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001158 ],
1159 "groups": []
Samuli Silvius7c41c162020-06-02 19:08:30 +03001160 }
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001161 ]
1162 }
1163
1164.. note:: For **Native Helm** path both modelName will have prefix *helm_* i.e. *helm_vfw* and vfModuleLabel will have *helm_* keyword inside i.e. *VfwCnfCdsVsp..helm_vfw..module-3*
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001165
1166- SDNC:
1167
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001168 SDNC should have it's database updated with *sdnc_* properties that were set during service modeling.
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001169
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +02001170.. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
1171
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001172
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001173::
1174
1175 kubectl -n onap exec onap-mariadb-galera-0 -it -- sh
1176 mysql -uroot -psecretpassword -D sdnctl
1177 MariaDB [sdnctl]> select sdnc_model_name, sdnc_model_version, sdnc_artifact_name from VF_MODEL WHERE customization_uuid = '86dc8af4-aa17-4fc7-9b20-f12160d99718';
1178 +-----------------+--------------------+--------------------+
1179 | sdnc_model_name | sdnc_model_version | sdnc_artifact_name |
1180 +-----------------+--------------------+--------------------+
1181 | vFW_CNF_CDS | 7.0.0 | vnf |
1182 +-----------------+--------------------+--------------------+
1183 1 row in set (0.00 sec)
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001184
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001185
1186.. note:: customization_uuid value is the modelCustomizationUuid of the VNF (serviceVnfs response in 2nd Postman call from SO Catalog DB)
Konrad Bańkacc67f632020-03-12 12:09:13 +01001187
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001188- CDS:
1189
1190 CDS should onboard CBA uploaded as part of VF.
1191
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001192 ::
1193
1194 Postman -> Distribution Verification -> [CDS] List CBAs
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001195
1196 ::
1197
Samuli Silvius7c41c162020-06-02 19:08:30 +03001198 [
1199 {
1200 "blueprintModel": {
1201 "id": "c505e516-b35d-4181-b1e2-bcba361cfd0a",
1202 "artifactUUId": null,
1203 "artifactType": "SDNC_MODEL",
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001204 "artifactVersion": "7.0.0",
1205 "artifactDescription": "Controller Blueprint for vFW_CNF_CDS:7.0.0",
Samuli Silvius7c41c162020-06-02 19:08:30 +03001206 "internalVersion": null,
1207 "createdDate": "2020-05-29T06:02:20.000Z",
1208 "artifactName": "vFW_CNF_CDS",
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001209 "published": "N",
Samuli Silvius7c41c162020-06-02 19:08:30 +03001210 "updatedBy": "Samuli Silvius <s.silvius@partner.samsung.com>",
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001211 "tags": "Samuli Silvius, Lukasz Rajewski, vFW_CNF_CDS"
Samuli Silvius7c41c162020-06-02 19:08:30 +03001212 }
1213 }
1214 ]
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001215
1216 The list should have the matching entries with SDNC database:
1217
1218 - sdnc_model_name == artifactName
1219 - sdnc_model_version == artifactVersion
1220
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001221 You can also use Postman to download CBA for further verification but it's fully optional.
1222
1223 ::
1224
1225 Postman -> Distribution Verification -> [CDS] CBA Download
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001226
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001227- K8splugin:
1228
1229 K8splugin should onboard 4 resource bundles related to helm resources:
1230
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001231 ::
1232
1233 Postman -> Distribution Verification -> [K8splugin] List Resource Bundle Definitions
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001234
1235 ::
1236
Samuli Silvius7c41c162020-06-02 19:08:30 +03001237 [
1238 {
1239 "rb-name": "52842255-b7be-4a1c-ab3b-2bd3bd4a5423",
1240 "rb-version": "274f4bc9-7679-4767-b34d-1df51cdf2496",
1241 "chart-name": "base_template",
1242 "description": "",
1243 "labels": {
1244 "vnf_customization_uuid": "b27fad11-44da-4840-9256-7ed8a32fbe3e"
1245 }
1246 },
1247 {
1248 "rb-name": "36f25e1b-199b-4de2-b656-c870d341cf0e",
1249 "rb-version": "0cbf558f-5a96-4555-b476-7df8163521aa",
1250 "chart-name": "vsn",
1251 "description": "",
1252 "labels": {
1253 "vnf_customization_uuid": "4cac0584-c0d6-42a7-bdb3-29162792e07f"
1254 }
1255 },
1256 {
1257 "rb-name": "4e2b9975-5214-48b8-861a-5701c09eedfa",
1258 "rb-version": "011b5f61-6524-4789-bd9a-44cfbf321463",
1259 "chart-name": "vpkg",
1260 "description": "",
1261 "labels": {
1262 "vnf_customization_uuid": "4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb"
1263 }
1264 },
1265 {
1266 "rb-name": "9ffda670-3d77-4f6c-a4ad-fb7a09f19817",
1267 "rb-version": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f",
1268 "chart-name": "vfw",
1269 "description": "",
1270 "labels": {
1271 "vnf_customization_uuid": "1e123e43-ba40-4c93-90d7-b9f27407ec03"
1272 }
1273 }
1274 ]
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001275
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001276**<AUTOMATED>**
1277
1278Distribution is a part of the onboarding step and at this stage is performed
1279
Samuli Silviusa58b0b42020-02-18 10:00:47 +020012803-2 CNF Instantiation
mrichommee4643892020-11-30 18:31:29 +01001281.....................
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001282
1283This is the whole beef of the use case and furthermore the core of it is that we can instantiate any amount of instances of the same CNF each running and working completely of their own. Very basic functionality in VM (VNF) side but for Kubernetes and ONAP integration this is the first milestone towards other normal use cases familiar for VNFs.
1284
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001285**<MANUAL>**
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001286
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001287Postman collection is automated to populate needed parameters when queries are run in correct order. If you did not already run following 2 queries after distribution (to verify distribution), run those now:
1288
1289::
1290
1291 Postman -> LCM -> 1.[SDC] Catalog Service
1292
1293::
1294
1295 Postman -> LCM -> 2. [SO] Catalog DB Service xNFs
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001296
1297Now actual instantiation can be triggered with:
1298
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001299::
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001300
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001301 Postman -> LCM -> 3. [SO] Self-Serve Service Assign & Activate
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001302
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001303**<AUTOMATED>**
1304
1305Required inputs for instantiation process are taken from the *config.py* file.
1306::
1307
1308 python instantiation.py
1309
1310
1311Finally, to follow the progress of instantiation request with SO's GET request:
1312
1313**<MANUAL>**
1314
1315::
1316
1317 Postman -> LCM -> 4. [SO] Infra Active Requests
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001318
1319The successful reply payload in that query should start like this:
1320
1321::
1322
1323 {
Konrad Bańka38af9cf2020-06-01 09:36:09 +02001324 "requestStatus": "COMPLETE",
1325 "statusMessage": "Macro-Service-createInstance request was executed correctly.",
1326 "flowStatus": "Successfully completed all Building Blocks",
1327 "progress": 100,
1328 "startTime": 1590996766000,
1329 "endTime": 1590996945000,
1330 "source": "Postman",
1331 "vnfId": "93b3350d-ed6f-413b-9cc5-a158c1676eb0",
1332 "tenantId": "aaaa",
1333 "requestBody": "**REDACTED FOR READABILITY**",
1334 "lastModifiedBy": "CamundaBPMN",
1335 "modifyTime": "2020-06-01T07:35:45.000+0000",
1336 "cloudRegion": "k8sregionfour",
1337 "serviceInstanceId": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72",
1338 "serviceInstanceName": "vfw-cnf-16",
1339 "requestScope": "service",
1340 "requestAction": "createInstance",
1341 "requestorId": "11c2ddb7-4659-4bf0-a685-a08dcbb5a099",
1342 "requestUrl": "http://infra:30277/onap/so/infra/serviceInstantiation/v7/serviceInstances",
1343 "tenantName": "k8stenant",
1344 "cloudApiRequests": [],
1345 "requestURI": "6a369c8e-d492-4ab5-a107-46804eeb7873",
1346 "_links": {
1347 "self": {
1348 "href": "http://infra:30277/infraActiveRequests/6a369c8e-d492-4ab5-a107-46804eeb7873"
1349 },
1350 "infraActiveRequests": {
1351 "href": "http://infra:30277/infraActiveRequests/6a369c8e-d492-4ab5-a107-46804eeb7873"
1352 }
1353 }
1354 }
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001355
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001356
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001357Progress can be also followed also with `SO Monitoring`_ dashboard.
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +02001358
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001359Service Instance Termination
1360++++++++++++++++++++++++++++
Lukasz Rajewskic1b4bda2020-05-25 19:05:41 +02001361
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001362Service instance can be terminated with the following postman call:
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001363
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001364**<MANUAL>**
1365::
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001366
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001367 Postman -> LCM -> 5. [SO] Service Delete
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001368
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001369**<AUTOMATED>**
1370::
1371
1372 python delete.py
1373
1374.. note:: Automated service deletion mecvhanism takes information about the instantiated service instance from the *config.py* file and *SERVICE_INSTANCE_NAME* variable. If you modify this value before the deletion of existing service instance then you will loose opportunity to easy delete already created service instance.
1375
1376Second Service Instance Instantiation
1377+++++++++++++++++++++++++++++++++++++
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001378
1379To finally verify that all the work done within this demo, it should be possible to instantiate second vFW instance successfully.
1380
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001381Trigger new instance createion. You can use previous call or a separate one that will utilize profile templating mechanism implemented in CBA:
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001382
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001383**<MANUAL>**
1384::
1385
1386 Postman -> LCM -> 6. [SO] Self-Serve Service Assign & Activate - Second
1387
1388**<AUTOMATED>**
1389
1390Before second instance of service is created you need to modify *config.py* file changing the *SERVICENAME* and *SERVICE_INSTANCE_NAME* to different values and by changing the value or *k8s-rb-profile-name* parameter for *vpg* module from value *default* or *vfw-cnf-cds-base-profile* to *vfw-cnf-cds-vpkg-profile* what will result with instantiation of additional ssh service for *vpg* module. Second onboarding in automated case is required due to the existing limitations of *python-sdk* librarier that create vf-module instance name base on the vf-module model name. For manual Postman option vf-module instance name is set on service instance name basis what makes it unique.
1391::
1392
1393 python onboarding.py
1394 python instantiation.py
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001395
13963-3 Results and Logs
mrichommee4643892020-11-30 18:31:29 +01001397....................
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001398
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001399Now multiple instances of Kubernetes variant of vFW are running in target VIM (KUD deployment).
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001400
1401.. figure:: files/vFW_CNF_CDS/vFW_Instance_In_Kubernetes.png
1402 :align: center
1403
1404 vFW Instance In Kubernetes
1405
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001406**<MANUAL>**
1407
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001408To review situation after instantiation from different ONAP components, most of the info can be found using Postman queries provided. For each query, example response payload(s) is/are saved and can be found from top right corner of the Postman window.
1409
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001410::
1411
1412 Postman -> Instantiation verification**
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001413
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001414Execute example Postman queries and check example section to see the valid results.
1415
1416========================== =================
1417Verify Target Postman query
1418-------------------------- -----------------
1419Service Instances in AAI **Postman -> Instantiation verification -> [AAI] List Service Instances**
1420Service Instances in MDSAL **Postman -> Instantiation verification -> [SDNC] GR-API MD-SAL Services**
1421K8S Instances in KUD **Postman -> Instantiation verification -> [K8splugin] List Instances**
1422========================== =================
1423
1424.. note:: "[AAI] List vServers <Empty>" Request won't return any vserver info from AAI, as currently such information are not provided during instantiation process.
1425
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001426
1427Query also directly from VIM:
1428
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001429::
1430
1431 #
1432 ubuntu@kud-host:~$ kubectl get pods,svc,networks,cm,network-attachment-definition,deployments
1433 NAME READY STATUS RESTARTS AGE
Konrad Bańkacc67f632020-03-12 12:09:13 +01001434 pod/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f-7cfb9949d9-8b5vg 1/1 Running 0 22s
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001435 pod/vfw-19571429-4af4-49b3-af65-2eb1f97bba43-75cd7c6f76-4gqtz 1/1 Running 0 11m
1436 pod/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-f4485d485-pln8m 1/1 Running 0 11m
1437 pod/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-6f8cff54d-dvw4j 1/1 Running 0 32s
1438 pod/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-5879c56fd-q59l7 2/2 Running 0 11m
1439 pod/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-5889b7455-96j9d 2/2 Running 0 30s
1440
1441 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001442 service/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-management-api NodePort 10.244.43.245 <none> 2831:30831/TCP 11m
1443 service/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-management-api NodePort 10.244.1.45 <none> 2831:31831/TCP 33s
1444 service/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-darkstat-ui NodePort 10.244.16.187 <none> 667:30667/TCP 11m
1445 service/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-darkstat-ui NodePort 10.244.20.229 <none> 667:31667/TCP 30s
1446
1447 NAME AGE
1448 network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-management-network 40s
1449 network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-protected-network 40s
1450 network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-unprotected-network 40s
1451 network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-management-network 11m
1452 network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-protected-network 11m
1453 network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-unprotected-network 11m
1454
1455 NAME DATA AGE
1456 configmap/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f-configmap 6 22s
1457 configmap/vfw-19571429-4af4-49b3-af65-2eb1f97bba43-configmap 6 11m
1458 configmap/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-configmap 6 11m
1459 configmap/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-configmap 6 33s
1460 configmap/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-configmap 2 11m
1461 configmap/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-configmap 2 30s
1462
1463 NAME AGE
1464 networkattachmentdefinition.k8s.cni.cncf.io/55118b80-8470-4c99-bfdf-d122cd412739-ovn-nat 40s
1465 networkattachmentdefinition.k8s.cni.cncf.io/567cecc3-9692-449e-877a-ff0b560736be-ovn-nat 11m
1466
1467 NAME READY UP-TO-DATE AVAILABLE AGE
Konrad Bańkacc67f632020-03-12 12:09:13 +01001468 deployment.extensions/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f 1/1 1 1 22s
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001469 deployment.extensions/vfw-19571429-4af4-49b3-af65-2eb1f97bba43 1/1 1 1 11m
1470 deployment.extensions/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e 1/1 1 1 11m
1471 deployment.extensions/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26 1/1 1 1 33s
1472 deployment.extensions/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14 1/1 1 1 11m
1473 deployment.extensions/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b 1/1 1 1 30s
1474
1475
1476Component Logs From The Execution
mrichommee4643892020-11-30 18:31:29 +01001477+++++++++++++++++++++++++++++++++
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001478
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001479**<MANUAL>**
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001480
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001481All logs from the use case execution can be retrieved with following
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001482
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001483::
1484
1485 kubectl -n onap logs `kubectl -n onap get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep -m1 <COMPONENT_NAME>` -c <CONTAINER>
1486
1487where <COMPONENT_NAME> and <CONTAINER> should be replaced with following keywords respectively:
1488
1489- so-bpmn-infra, so-bpmn-infra
1490- so-openstack-adapter, so-openstack-adapter
1491- so-cnf-adapter, so-cnf-adapter
1492- sdnc-0, sdnc
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001493
1494 From karaf.log all requests (payloads) to CDS can be found by searching following string:
1495
1496 ``'Sending request below to url http://cds-blueprints-processor-http:8080/api/v1/execution-service/process'``
1497
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001498- cds-blueprints-processor, cds-blueprints-processor
1499- multicloud-k8s, multicloud-k8s
1500- network-name-gen, network-name-gen,
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001501
mrichommee4643892020-11-30 18:31:29 +01001502**Debug log**
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001503
1504In case more detailed logging is needed, here's instructions how to setup DEBUG logging for few components.
1505
1506- SDNC
1507
1508 ::
1509
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001510 kubectl -n onap exec -it onap-sdnc-0 -c sdnc /opt/opendaylight/bin/client log:set DEBUG
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001511
1512
1513- CDS Blueprint Processor
1514
1515 ::
1516
1517 # Edit configmap
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001518 kubectl -n onap edit configmap onap-cds-blueprints-processor-configmap
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001519
1520 # Edit logback.xml content change root logger level from info to debug.
1521 <root level="debug">
1522 <appender-ref ref="STDOUT"/>
1523 </root>
1524
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001525 # Delete the Pods to make changes effective
1526 kubectl -n onap delete pods -l app=cds-blueprints-processor
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001527
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +010015283-4 Verification of the CNF Status
1529..................................
1530
1531**<MANUAL>**
1532
1533The Guilin introduces new API for verification of the status of instantiated resouces in k8s cluster. The API gives result similar to *kubectl describe* operation for all the resources created for particular *rb-definition*. Status API can be used to verify the k8s resources after instantiation but also can be used leveraged for synchronization of the information with external components, like AAI in the future. To use Status API call
1534
1535::
1536
1537 curl -i http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/{rb-instance-id}/status
1538
1539where {rb-instance-id} can be taken from the list of instances resolved the following call
1540
1541::
1542
1543 curl -i http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/
1544
1545or from AAI *heat-stack-id* property of created *vf-module* associated with each Helm package from onboarded VSP which holds the *rb-instance-id* value.
1546
Lukasz Rajewskidd9bf992020-12-30 18:43:39 +01001547Examplary output of Status API is shown below (full result of test vFW CNF helm package in the attached file). It shows the list of GVK resources created for requested *rb-instance* (Helm and vf-module in the same time) with assocated describe result for all of them.
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001548
Lukasz Rajewskidd9bf992020-12-30 18:43:39 +01001549 :download:`Full Status API Result <files/vFW_CNF_CDS/status-response.json>`
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001550
1551::
1552
1553 {
1554 "request": {
1555 "rb-name": "vfw",
1556 "rb-version": "plugin_test",
1557 "profile-name": "test_profile",
1558 "release-name": "",
1559 "cloud-region": "kud",
1560 "labels": {
1561 "testCaseName": "plugin_fw.sh"
1562 },
1563 "override-values": {
1564 "global.onapPrivateNetworkName": "onap-private-net-test"
1565 }
1566 },
1567 "ready": false,
Lukasz Rajewskidd9bf992020-12-30 18:43:39 +01001568 "resourceCount": 1,
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001569 "resourcesStatus": [
1570 {
1571 "name": "sink-configmap",
1572 "GVK": {
1573 "Group": "",
1574 "Version": "v1",
1575 "Kind": "ConfigMap"
1576 },
1577 "status": {
1578 "apiVersion": "v1",
1579 "data": {
1580 "protected_net_gw": "192.168.20.100",
1581 "protected_private_net_cidr": "192.168.10.0/24"
1582 },
1583 "kind": "ConfigMap",
1584 "metadata": {
1585 "creationTimestamp": "2020-09-29T13:36:25Z",
1586 "labels": {
1587 "k8splugin.io/rb-instance-id": "practical_nobel"
1588 },
1589 "name": "sink-configmap",
1590 "namespace": "plugin-tests-namespace",
1591 "resourceVersion": "10720771",
1592 "selfLink": "/api/v1/namespaces/plugin-tests-namespace/configmaps/sink-configmap",
1593 "uid": "46c8bec4-980c-455b-9eb0-fb84ac8cc450"
1594 }
1595 }
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001596 }
1597 ]
1598 }
1599
Lukasz Rajewskidd9bf992020-12-30 18:43:39 +01001600.. note:: The example of how the Stauts API could be integrated into CDS can be found in the Frankfurt version of k8s profile upload mechanism `Frankfurt CBA Definition`_ (*profile-upload* TOSCA node template), implemented in inside of the Kotlin script `Frankfurt CBA Script`_ for profile upload. This method shows how to integrate mutlicloud-k8s API endpoint into Kotlin script executed by CDS. For more details please take a look into Definition file of 1.0.45 version of the CBA and also the kotlin script used there for uploading the profile.
1601
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001602PART 4 - Future improvements needed
Lukasz Rajewskidd9bf992020-12-30 18:43:39 +01001603~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001604
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001605Future development areas for this use case:
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001606
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001607- Automated smoke use case.
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001608- Include Closed Loop part of the vFW demo.
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001609- vFW service with Openstack VNF and Kubernetes CNF
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001610
1611Future development areas for CNF support:
1612
1613- Validation of Helm package and extraction of override values in time of the package onboarding.
1614- Post instantiation configuration with Day 2 configuration APIs of multicloud/k8S API.
1615- Synchroinzation of information about CNF between AAI and K8s.
1616- Validation of status and health of CNF.
1617- Use multicloud/k8S API v2.
1618
1619Many features from the list above are covered by the Honolulu roadmap described in `REQ-458`_.
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001620
1621
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001622.. _ONAP Deployment Guide: https://docs.onap.org/projects/onap-oom/en/guilin/oom_quickstart_guide.html
1623.. _CDS Documentation: https://docs.onap.org/projects/onap-ccsdk-cds/en/guilin/index.html
Konrad Bańkac01b1fb2020-05-27 15:25:56 +02001624.. _vLB use-case: https://wiki.onap.org/pages/viewpage.action?pageId=71838898
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001625.. _vFW_CNF_CDS Model: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates?h=guilin
1626.. _vFW_CNF_CDS Automation: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/automation?h=guilin
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001627.. _vFW CDS Dublin: https://wiki.onap.org/display/DW/vFW+CDS+Dublin
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001628.. _vFW CBA Model: https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/service-blueprint/vFW?h=elalto
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001629.. _vFW_Helm Model: https://git.onap.org/multicloud/k8s/tree/kud/demo/firewall?h=elalto
1630.. _vFW_NextGen: https://git.onap.org/demo/tree/heat/vFW_NextGen?h=elalto
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001631.. _vFW EDGEX K8S: https://docs.onap.org/en/elalto/submodules/integration.git/docs/docs_vfw_edgex_k8s.html
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001632.. _vFW EDGEX K8S In ONAP Wiki: https://wiki.onap.org/display/DW/Deploying+vFw+and+EdgeXFoundry+Services+on+Kubernets+Cluster+with+ONAP
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001633.. _KUD github: https://github.com/onap/multicloud-k8s/tree/master/kud/hosting_providers/baremetal
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001634.. _KUD in Wiki: https://wiki.onap.org/display/DW/Kubernetes+Baremetal+deployment+setup+instructions
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001635.. _Multicloud k8s gerrit: https://gerrit.onap.org/r/q/status:open+project:+multicloud/k8s
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001636.. _KUD subproject in github: https://github.com/onap/multicloud-k8s/tree/master/kud
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001637.. _Frankfurt CBA Definition: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba/Definitions/vFW_CNF_CDS.json?h=frankfurt
1638.. _Frankfurt CBA Script: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba/Scripts/kotlin/KotlinK8sProfileUpload.kt?h=frankfurt
1639.. _SO-3403: https://jira.onap.org/browse/SO-3403
1640.. _SO-3404: https://jira.onap.org/browse/SO-3404
1641.. _REQ-182: https://jira.onap.org/browse/REQ-182
1642.. _REQ-341: https://jira.onap.org/browse/REQ-341
1643.. _REQ-458: https://jira.onap.org/browse/REQ-458
1644.. _Python SDK: https://docs.onap.org/projects/onap-integration/en/guilin/integration-tooling.html?highlight=python-sdk#python-onapsdk
Samuli Silviusa58b0b42020-02-18 10:00:47 +02001645.. _KUD Jenkins ci/cd verification: https://jenkins.onap.org/job/multicloud-k8s-master-kud-deployment-verify-shell/
Lukasz Rajewskiee41f3b2020-12-22 00:30:02 +01001646.. _K8s cloud site config: https://docs.onap.org/en/guilin/guides/onap-operator/cloud_site/k8s/index.html
1647.. _SO Monitoring: https://docs.onap.org/projects/onap-so/en/guilin/developer_info/Working_with_so_monitoring.html
1648.. _Data Dictionary: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba-dd.json?h=guilin
1649.. _Helm Healer: https://git.onap.org/oom/offline-installer/tree/tools/helm-healer.sh?h=frankfurt
mrichommea958b982020-04-13 18:46:35 +02001650.. _CDS UAT Testing: https://wiki.onap.org/display/DW/Modeling+Concepts
mrichomme20a4dbd2020-07-08 17:52:13 +02001651.. _infra_workload: https://docs.onap.org/projects/onap-multicloud-framework/en/latest/specs/multicloud_infra_workload.html?highlight=multicloud