1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
2 .. http://creativecommons.org/licenses/by/4.0
11 ----------------------
12 vFirewall CNF Use Case
13 ----------------------
17 - Heat/Helm/CDS models: `vFW_CNF_CDS Model`_
21 This 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`_.
23 In a higher level this use case brings only two improvements yet important ones i.e. the ability to instantiate more than single CNF instance of same type (with same Helm package) and ability to embed into singular onboarding package more than one helm package what brings more service design options.
25 Following improvements were made in the Use Case or related ONAP components:
27 - Changed vFW Kubernetes Helm charts to support overrides (previously mostly hardcoded values)
28 - Combined all models (Heat, Helm, CBA) in to same git repo and a creating single onboarding package `vFW_CNF_CDS Model`_
29 - Compared to `vFW EDGEX K8S`_ use case **MACRO** workflow in SO is used instead of VNF a'la carte workflow. (this is general requirement to utilize CDS as part of instantiation flow)
30 - SDC accepts Onboarding Package with many helm packages what allows to keep decomposition of service instance similar to `vFW CDS Dublin`_
31 - CDS is used to resolve instantiation time parameters (Helm override)
32 - Ip addresses with IPAM
33 - Unique names for resources with ONAP naming service
34 - Multicloud/k8s plugin changed to support identifiers of vf-module concept
35 - **multicloud/k8s** creates automatically default empty RB profile and profile upload becomes optional for instantiation of CNF
36 - CDS is used to create **multicloud/k8s profile** as part of instantiation flow (previously manual step)
38 Use case does not contain Closed Loop part of the vFW demo.
42 The 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.
44 One 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.
46 Demo git directory has also `Data Dictionary`_ file (CDS model time resource) included.
48 Another 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.
50 Following table describes all the source models to which this demo is based on.
52 =============== ================= ===========
53 Model Git reference Description
54 --------------- ----------------- -----------
55 Heat `vFW_NextGen`_ Heat templates used in original vFW demo but split into multiple vf-modules
56 Helm `vFW_Helm Model`_ Helm templates used in `vFW EDGEX K8S`_ demo
57 CDS model `vFW CBA Model`_ CDS CBA model used in `vFW CDS Dublin`_ demo
58 =============== ================= ===========
60 All changes to related ONAP components and Use Case can be found from this `Jira Epic`_ ticket.
62 Modeling Onboarding Package/Helm
63 ................................
65 The 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.
67 Produced onboarding package has following MANIFEST file (package/MANIFEST.json) having all Helm packages modeled as dummy Heat resources matching to vf-module concept (that is originated from Heat), so basically each Helm application is visible to ONAP as own vf-module. Actual 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 of the file name.
69 CDS model (CBA package) is delivered as SDC supported own type CONTROLLER_BLUEPRINT_ARCHIVE.
74 "name": "virtualFirewall",
78 "file": "vFW_CDS_CNF.zip",
79 "type": "CONTROLLER_BLUEPRINT_ARCHIVE"
82 "file": "base_template.yaml",
87 "file": "base_template.env",
93 "file": "base_template_cloudtech_k8s_charts.tgz",
94 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
108 "file": "vfw_cloudtech_k8s_charts.tgz",
109 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
123 "file": "vpkg_cloudtech_k8s_charts.tgz",
124 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
138 "file": "vsn_cloudtech_k8s_charts.tgz",
139 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
147 K8s plugin was changed to support new way to identify k8s application and related multicloud/k8s profile.
151 - SDC distribution broker
153 SDC distribution broker is responsible for transformation of the CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT into *Definition* object holding the helm package. The change for Frankfurt release considers that singular onboarding package can have many CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT, each one for dedicated vf-module associated with dummy heat template. The mapping between vf-module and CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT is done on file prefixes. In example, *vfw.yaml* Heat template will result with creation of *vfw* vf-module and its Definition will be created from CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT file of name vfw_cloudtech_k8s_charts.tgz. More examples can be found in `Modeling Onboarding Package/Helm`_ section.
155 - K8S plugin APIs changed to use VF Module Model Identifiers
157 Previously K8S plugin's used user given values in to identify object created/modified. Names were basing on VF-Module's "model-name"/"model-version" like "VfwLetsHopeLastOne..vfw..module-3" and "1". SO request has user_directives from where values was taken.
159 **VF Module Model Invariant ID** and **VF Module Model Version ID** is now used to identify artifact in SO request to Multicloud/k8s plugin. This does not require user to give extra parameters for the SO request as vf-module related parameters are there already by default. `MULTICLOUD-941`_
160 Note that API endpoints are not changed but only the semantics.
168 /api/multicloud-k8s/v1/v1/rb/definition/{VF Module Model Invariant ID}/{VF Module Model Version ID}/content
175 curl -i -d @create_rbprofile.json -X POST http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/rb/definition/{VF Module Model Invariant ID}/{VF Module Model Version ID}/profile
176 { "rb-name": “{VF Module Model Invariant ID}",
177 "rb-version": "{VF Module Model Version ID}",
178 "profile-name": "p1",
179 "release-name": "r1",
180 "namespace": "testns1",
181 "kubernetes-version": "1.13.5"
184 Upload Profile content API
188 curl -i --data-binary @profile.tar.gz -X POST http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/rb/definition/{VF Module Model Invariant ID}/{VF Module Model Version ID}/profile/p1/content
190 - Instantiation broker
192 The broker implements `infra_workload`_ API used to handle vf-module instantiation request comming from the SO. User directives were changed by SDNC directives what impacts also the way how a'la carte instantiation method works from the VID. There is no need to specify the user directives delivered from the separate file. Instead SDNC directives are delivered through SDNC preloading (a'la carte instantiation) or through the resource assignment performed by the CDS (Macro flow instantiation).
195 For helm package instantiation following parameters have to be delivered in the SDNC directives:
198 ======================== ==============================================
202 ------------------------ ----------------------------------------------
204 k8s-rb-profile-name Name of the override profile
206 k8s-rb-profile-namespace Name of the namespace for created helm package
208 ======================== ==============================================
210 - Default profile support was added to the plugin
212 K8splugin now creates dummy "default" profile on each resource bundle registration. Such profile doesn't contain any content inside and allows instantiation of CNF without the need to define additional profile, however this is still possible. In this use-case, CBA has been defined in a way, that it can template some simple profile that can be later put by CDS during resource-assignment instantiation phase and later picked up for instantiation. This happens when using second prepared instantiation call for instantiation: **Postman -> LCM -> 6. [SO] Self-Serve Service Assign & Activate - Second**
214 - Instantiation time override support was added to the plugin
216 K8splugin allows now specifying 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.
222 Creating CDS model was the core of the use case work and also the most difficult and time consuming part. There are many reasons for this e.g.
224 - CDS documentation (even being new component) is inadequate or non-existent for service modeler user. One would need to be CDS developer to be able to do something with it.
225 - CDS documentation what exists is non-versioned (in ONAP wiki when should be in git) so it's mostly impossible to know what features are for what release.
226 - Our little experience of CDS (not CDS developers)
228 Although initial development of template wasn't easy, 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 Modeling Concepts`_.
230 At 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.
232 As 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.
237 "base_template-template" : {
238 "type" : "artifact-template-velocity",
239 "file" : "Templates/base_template-template.vtl"
241 "base_template-mapping" : {
242 "type" : "artifact-mapping-resource",
243 "file" : "Templates/base_template-mapping.json"
246 "type" : "artifact-template-velocity",
247 "file" : "Templates/vpkg-template.vtl"
250 "type" : "artifact-mapping-resource",
251 "file" : "Templates/vpkg-mapping.json"
254 "type" : "artifact-template-velocity",
255 "file" : "Templates/vfw-template.vtl"
258 "type" : "artifact-mapping-resource",
259 "file" : "Templates/vfw-mapping.json"
262 "type" : "artifact-template-velocity",
263 "file" : "Templates/vnf-template.vtl"
266 "type" : "artifact-mapping-resource",
267 "file" : "Templates/vnf-mapping.json"
270 "type" : "artifact-template-velocity",
271 "file" : "Templates/vsn-template.vtl"
274 "type" : "artifact-mapping-resource",
275 "file" : "Templates/vsn-mapping.json"
279 Only **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.
281 Another 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.
282 RB 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
283 modify existing k8s helm templates for each create CNF instance. It opens another level of CNF customization, much more than customization og helm package with override values.
290 values: “override_values.yaml”
292 - filepath: resources/deployment.yaml
293 chartpath: templates/deployment.yaml
296 Above 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
297 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.
299 In order to support generation and upload of profile, our vFW CBA model has enhanced **resource-assignment** workflow which contains additional steps, **profile-modification** and **profile-upload**. For the last step custom Kotlin script included in the CBA is used to upload K8S profile into multicloud/k8s plugin.
303 "resource-assignment": {
305 "resource-assignment": {
306 "description": "Resource Assign Workflow",
307 "target": "resource-assignment",
310 "call_operation": "ResourceResolutionComponent.process"
314 "profile-modification"
317 "profile-modification": {
318 "description": "Profile Modification Resources",
319 "target": "profile-modification",
322 "call_operation": "ResourceResolutionComponent.process"
330 "description": "Upload K8s Profile",
331 "target": "profile-upload",
334 "call_operation": "ComponentScriptExecutor.process"
340 Profile generation step uses embedded into CDS functionality of templates processing and on its basis ssh port number (specified in the SO request as vpg-management-port) is included in the ssh service helm template.
347 name: {{ .Values.vpg_name_0 }}-ssh-access
349 vnf-name: {{ .Values.vnf_name }}
350 vf-module-name: {{ .Values.vpg_name_0 }}
351 release: {{ .Release.Name }}
352 chart: {{ .Chart.Name }}
357 nodePort: ${vpg-management-port}
359 vf-module-name: {{ .Values.vpg_name_0 }}
360 release: {{ .Release.Name }}
361 chart: {{ .Chart.Name }}
363 To upload of the profile is conducted with the CDS capability to execute Kotlin scripts. It allows to define any required controller logic. In our case we use to implement decision point and mechanisms of profile generation and upload.
364 During the generation CDS extracts the RB profile template included in the CBA, includes there generated ssh service helm template, modifies the manifest of RB template by adding there ssh service and after its archivisation sends the profile to
369 "profile-modification": {
370 "type": "component-resource-resolution",
372 "ResourceResolutionComponent": {
376 "artifact-prefix-names": [
385 "ssh-service-template": {
386 "type": "artifact-template-velocity",
387 "file": "Templates/k8s-profiles/ssh-service-template.vtl"
389 "ssh-service-mapping": {
390 "type": "artifact-mapping-resource",
391 "file": "Templates/k8s-profiles/ssh-service-mapping.json"
396 "type": "component-script-executor",
398 "ComponentScriptExecutor": {
402 "script-type": "kotlin",
403 "script-class-reference": "org.onap.ccsdk.cds.blueprintsprocessor.services.execution.scripts.K8sProfileUpload",
404 "dynamic-properties": "*profile-upload-properties"
412 Kotlin script expects that K8S profile template named like "k8s-rb-profile-name".tar.gz is present in CBA "Templates/k8s-profiles" directory where **k8s-rb-profile-name** is one of the CDS resolved parameters (user provides as input parameter) and in our case it has a value **vfw-cnf-cds-base-profile**.
414 Finally, `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.
420 UAT is a nice concept where CDS CBA can be tested isolated after all external calls it makes are recorded. UAT framework in CDS has spy mode that enables such recording of requets. Recording is initiated with structured yaml file having all CDS requests and spy mode executes all those requests in given yaml file and procuding another yaml file where external requetsts and payloads are recorded.
422 During this use case we had several problems with UAT testing and finally we where not able to get it fully working. UAT framework is not taking consideration that of subsequent CDS calls does have affects to external componenets like SDNC MDSAL (particularly the first resource-assignment call comING FROM sdnc stored resolved values to MDSAL and those are needed by subsequent calls by CBA model).
424 It was possible to record CDS calls with UAT spy after successfull instantition when SDNC was alredy populated with resolved values are re-run of CDS model was able to fetch needed values.
426 During testing of the use case **uat.yml** file was recorded according to `CDS UAT Testing`_ instructions. Generated uat.yml could be stored (if usable) within CBA package into **Tests** folder.
428 Recorded uat.yml is an example run with example values (the values we used when demo was run) and can be used later to test CBA model in isolation (unit test style). This could be very useful when changes are made to CBA model and those changes are needed to be tested fast. With uat.yml file only CDS is needed as all external interfaces are mocked. However, note that mocking is possible for REST interfaces only (e.g. Netconf is not supported).
430 Another benefit of uat.yml is that it documents the runtime functionality of the CBA and that's the main benefit on this use case as the UAT test (verify) part was not really successful.
432 To verify CBA with uat.yaml and CDS runtime do following:
434 - Enable UAT testing for CDS runtime
438 kubectl -n onap edit deployment onap-cds-blueprints-processor
440 # add env variable for cds-blueprints-processor container:
441 name: spring_profiles_active
444 - Spy CBA functionality with UAT initial seed file
448 curl -X POST -u ccsdkapps:ccsdkapps -F cba=@my_cba.zip -F uat=@input_uat.yaml http://<kube-node>:30499/api/v1/uat/spy
450 where my_cba.zip is the cba model of this use case and input_uat.yml is following in this use case:
457 - name: resource-assignment for vnf
459 commonHeader: &commonHeader
460 originatorId: SDNC_DG
461 requestId: "98397f54-fa57-485f-a04e-1e220b7b1779"
462 subRequestId: "6bfca5dc-993d-48f1-ad27-a7a9ea91836b"
463 actionIdentifiers: &actionIdentifiers
464 blueprintName: vFW_CNF_CDS
465 blueprintVersion: "1.0.45"
466 actionName: resource-assignment
469 resource-assignment-request:
472 resource-assignment-properties:
473 service-instance-id: &service-id "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
474 vnf-model-customization-uuid: &vnf-model-cust-uuid "86dc8af4-aa17-4fc7-9b20-f12160d99718"
475 vnf-id: &vnf-id "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
476 aic-cloud-region: &cloud-region "k8sregionfour"
477 - name: resource-assignment for base_template
479 commonHeader: *commonHeader
480 actionIdentifiers: *actionIdentifiers
482 resource-assignment-request:
485 resource-assignment-properties:
486 nfc-naming-code: "base_template"
487 k8s-rb-profile-name: &k8s-profile-name "default"
488 service-instance-id: *service-id
490 vf-module-model-customization-uuid: "b27fad11-44da-4840-9256-7ed8a32fbe3e"
491 vnf-model-customization-uuid: *vnf-model-cust-uuid
492 vf-module-id: "274f4bc9-7679-4767-b34d-1df51cdf2496"
493 aic-cloud-region: *cloud-region
494 - name: resource-assignment for vpkg
496 commonHeader: *commonHeader
497 actionIdentifiers: *actionIdentifiers
499 resource-assignment-request:
502 resource-assignment-properties:
503 nfc-naming-code: "vpkg"
504 k8s-rb-profile-name: *k8s-profile-name
505 service-instance-id: *service-id
507 vf-module-model-customization-uuid: "4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb"
508 vnf-model-customization-uuid: *vnf-model-cust-uuid
509 vf-module-id: "011b5f61-6524-4789-bd9a-44cfbf321463"
510 aic-cloud-region: *cloud-region
511 - name: resource-assignment for vsn
513 commonHeader: *commonHeader
514 actionIdentifiers: *actionIdentifiers
516 resource-assignment-request:
519 resource-assignment-properties:
520 nfc-naming-code: "vsn"
521 k8s-rb-profile-name: *k8s-profile-name
522 service-instance-id: *service-id
524 vf-module-model-customization-uuid: "4cac0584-c0d6-42a7-bdb3-29162792e07f"
525 vnf-model-customization-uuid: *vnf-model-cust-uuid
526 vf-module-id: "0cbf558f-5a96-4555-b476-7df8163521aa"
527 aic-cloud-region: *cloud-region
528 - name: resource-assignment for vfw
530 commonHeader: *commonHeader
531 actionIdentifiers: *actionIdentifiers
533 resource-assignment-request:
536 resource-assignment-properties:
537 nfc-naming-code: "vfw"
538 k8s-rb-profile-name: *k8s-profile-name
539 service-instance-id: *service-id
541 vf-module-model-customization-uuid: "1e123e43-ba40-4c93-90d7-b9f27407ec03"
542 vnf-model-customization-uuid: *vnf-model-cust-uuid
543 vf-module-id: "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f "
544 aic-cloud-region: *cloud-region
547 .. note:: This call will run all the calls (given in input_uat.yml) towards CDS and records the functionality, so there needs to be working environment (SDNC, AAI, Naming, Netbox, etc.) to record valid final uat.yml.
548 As an output of this call final uat.yml content is received. Final uat.yml in this use case looks like this:
553 - name: resource-assignment for vnf
556 originatorId: SDNC_DG
557 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
558 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
560 blueprintName: vFW_CNF_CDS
561 blueprintVersion: 1.0.45
562 actionName: resource-assignment
565 resource-assignment-request:
568 resource-assignment-properties:
569 service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72
570 vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718
571 vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0
572 aic-cloud-region: k8sregionfour
575 originatorId: SDNC_DG
576 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
577 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
580 blueprintName: vFW_CNF_CDS
581 blueprintVersion: 1.0.45
582 actionName: resource-assignment
586 eventType: EVENT_COMPONENT_EXECUTED
590 resource-assignment-response:
596 "capability-name": "generate-name",
599 "output-key-mapping": [
601 "resource-name": "vnf_name",
602 "resource-value": "${vnf_name}"
607 "param-name": "resource-name",
608 "param-value": "vnf_name"
611 "param-name": "resource-value",
612 "param-value": "${vnf_name}"
615 "param-name": "external-key",
616 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0_vnf_name"
619 "param-name": "policy-instance-name",
620 "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP"
623 "param-name": "naming-type",
627 "param-name": "AIC_CLOUD_REGION",
628 "param-value": "k8sregionfour"
635 "capability-name": "netbox-ip-assign",
638 "output-key-mapping": [
640 "resource-name": "int_private1_gw_ip",
641 "resource-value": "${int_private1_gw_ip}"
646 "param-name": "service-instance-id",
647 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
650 "param-name": "prefix-id",
654 "param-name": "vnf-id",
655 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
658 "param-name": "external_key",
659 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-int_private1_gw_ip"
664 "output-key-mapping": [
666 "resource-name": "int_private2_gw_ip",
667 "resource-value": "${int_private2_gw_ip}"
672 "param-name": "service-instance-id",
673 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
676 "param-name": "prefix-id",
680 "param-name": "vnf-id",
681 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
684 "param-name": "external_key",
685 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-int_private2_gw_ip"
690 "output-key-mapping": [
692 "resource-name": "vfw_int_private2_ip_0",
693 "resource-value": "${vfw_int_private2_ip_0}"
698 "param-name": "service-instance-id",
699 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
702 "param-name": "prefix-id",
706 "param-name": "vnf-id",
707 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
710 "param-name": "external_key",
711 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vfw_int_private2_ip_0"
716 "output-key-mapping": [
718 "resource-name": "vfw_int_private1_ip_0",
719 "resource-value": "${vfw_int_private1_ip_0}"
724 "param-name": "service-instance-id",
725 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
728 "param-name": "prefix-id",
732 "param-name": "vnf-id",
733 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
736 "param-name": "external_key",
737 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vfw_int_private1_ip_0"
742 "output-key-mapping": [
744 "resource-name": "vsn_int_private2_ip_0",
745 "resource-value": "${vsn_int_private2_ip_0}"
750 "param-name": "service-instance-id",
751 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
754 "param-name": "prefix-id",
758 "param-name": "vnf-id",
759 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
762 "param-name": "external_key",
763 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vsn_int_private2_ip_0"
768 "output-key-mapping": [
770 "resource-name": "vpg_int_private1_ip_0",
771 "resource-value": "${vpg_int_private1_ip_0}"
776 "param-name": "service-instance-id",
777 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
780 "param-name": "prefix-id",
784 "param-name": "vnf-id",
785 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
788 "param-name": "external_key",
789 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vpg_int_private1_ip_0"
796 "capability-name": "unresolved-composite-data",
799 "output-key-mapping": [
801 "resource-name": "int_private2_net_id",
802 "resource-value": "${vnf_name}-protected-network"
805 "resource-name": "int_private1_net_id",
806 "resource-value": "${vnf_name}-unprotected-network"
809 "resource-name": "onap_private_net_id",
810 "resource-value": "${vnf_name}-management-network"
813 "resource-name": "net_attachment_definition",
814 "resource-value": "${vnf_name}-ovn-nat"
821 "resource-accumulator-resolved-data": [
823 "param-name": "vf-naming-policy",
824 "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP"
827 "param-name": "dcae_collector_ip",
828 "param-value": "10.0.4.1"
831 "param-name": "dcae_collector_port",
832 "param-value": "30235"
835 "param-name": "int_private1_net_cidr",
836 "param-value": "192.168.10.0/24"
839 "param-name": "int_private2_net_cidr",
840 "param-value": "192.168.20.0/24"
843 "param-name": "onap_private_net_cidr",
844 "param-value": "10.0.101.0/24"
847 "param-name": "demo_artifacts_version",
848 "param-value": "1.5.0"
851 "param-name": "k8s-rb-profile-name",
852 "param-value": "vfw-cnf-cds-base-profile"
855 "param-name": "k8s-rb-profile-namespace",
856 "param-value": "default"
860 - name: resource-assignment for base_template
863 originatorId: SDNC_DG
864 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
865 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
867 blueprintName: vFW_CNF_CDS
868 blueprintVersion: 1.0.45
869 actionName: resource-assignment
872 resource-assignment-request:
875 resource-assignment-properties:
876 nfc-naming-code: base_template
877 k8s-rb-profile-name: default
878 service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72
879 vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0
880 vf-module-model-customization-uuid: b27fad11-44da-4840-9256-7ed8a32fbe3e
881 vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718
882 vf-module-id: 274f4bc9-7679-4767-b34d-1df51cdf2496
883 aic-cloud-region: k8sregionfour
886 originatorId: SDNC_DG
887 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
888 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
891 blueprintName: vFW_CNF_CDS
892 blueprintVersion: 1.0.45
893 actionName: resource-assignment
897 eventType: EVENT_COMPONENT_EXECUTED
901 resource-assignment-response:
907 "capability-name": "netbox-ip-assign",
910 "output-key-mapping": [
912 "resource-name": "onap_private_gw_ip",
913 "resource-value": "${onap_private_gw_ip}"
918 "param-name": "service-instance-id",
919 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
922 "param-name": "prefix-id",
926 "param-name": "vnf-id",
927 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
930 "param-name": "external_key",
931 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-onap_private_gw_ip"
938 "capability-name": "generate-name",
941 "output-key-mapping": [
943 "resource-name": "vf_module_name",
944 "resource-value": "${vf-module-name}"
949 "param-name": "resource-name",
950 "param-value": "vf_module_name"
953 "param-name": "resource-value",
954 "param-value": "${vf-module-name}"
957 "param-name": "external-key",
958 "param-value": "274f4bc9-7679-4767-b34d-1df51cdf2496_vf-module-name"
961 "param-name": "policy-instance-name",
962 "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP"
965 "param-name": "naming-type",
966 "param-value": "VF-MODULE"
969 "param-name": "VNF_NAME",
970 "param-value": "k8sregionfour-onap-nf-20200601t073308018z"
973 "param-name": "VF_MODULE_TYPE",
974 "param-value": "vfmt"
977 "param-name": "VF_MODULE_LABEL",
978 "param-value": "base_template"
985 "capability-name": "aai-vf-module-put",
988 "output-key-mapping": [
990 "resource-name": "aai-vf-module-put",
998 "resource-accumulator-resolved-data": [
1000 "param-name": "vf-module-model-invariant-uuid",
1001 "param-value": "52842255-b7be-4a1c-ab3b-2bd3bd4a5423"
1004 "param-name": "vf-module-model-version",
1005 "param-value": "274f4bc9-7679-4767-b34d-1df51cdf2496"
1008 "param-name": "k8s-rb-profile-name",
1009 "param-value": "default"
1012 "param-name": "k8s-rb-profile-namespace",
1013 "param-value": "default"
1016 "param-name": "int_private1_subnet_id",
1017 "param-value": "unprotected-network-subnet-1"
1020 "param-name": "int_private2_subnet_id",
1021 "param-value": "protected-network-subnet-1"
1024 "param-name": "onap_private_subnet_id",
1025 "param-value": "management-network-subnet-1"
1029 - name: resource-assignment for vpkg
1032 originatorId: SDNC_DG
1033 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
1034 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
1036 blueprintName: vFW_CNF_CDS
1037 blueprintVersion: 1.0.45
1038 actionName: resource-assignment
1041 resource-assignment-request:
1044 resource-assignment-properties:
1045 nfc-naming-code: vpkg
1046 k8s-rb-profile-name: default
1047 service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72
1048 vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0
1049 vf-module-model-customization-uuid: 4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb
1050 vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718
1051 vf-module-id: 011b5f61-6524-4789-bd9a-44cfbf321463
1052 aic-cloud-region: k8sregionfour
1055 originatorId: SDNC_DG
1056 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
1057 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
1060 blueprintName: vFW_CNF_CDS
1061 blueprintVersion: 1.0.45
1062 actionName: resource-assignment
1066 eventType: EVENT_COMPONENT_EXECUTED
1070 resource-assignment-response:
1074 "capability-data": [
1076 "capability-name": "netbox-ip-assign",
1079 "output-key-mapping": [
1081 "resource-name": "vpg_onap_private_ip_0",
1082 "resource-value": "${vpg_onap_private_ip_0}"
1087 "param-name": "service-instance-id",
1088 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
1091 "param-name": "prefix-id",
1095 "param-name": "vnf-id",
1096 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
1099 "param-name": "external_key",
1100 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vpg_onap_private_ip_0"
1107 "capability-name": "generate-name",
1110 "output-key-mapping": [
1112 "resource-name": "vf_module_name",
1113 "resource-value": "${vf-module-name}"
1118 "param-name": "VF_MODULE_TYPE",
1119 "param-value": "vfmt"
1122 "param-name": "resource-name",
1123 "param-value": "vf_module_name"
1126 "param-name": "resource-value",
1127 "param-value": "${vf-module-name}"
1130 "param-name": "external-key",
1131 "param-value": "011b5f61-6524-4789-bd9a-44cfbf321463_vf-module-name"
1134 "param-name": "policy-instance-name",
1135 "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP"
1138 "param-name": "naming-type",
1139 "param-value": "VF-MODULE"
1142 "param-name": "VNF_NAME",
1143 "param-value": "k8sregionfour-onap-nf-20200601t073308018z"
1146 "param-name": "VF_MODULE_LABEL",
1147 "param-value": "vpkg"
1154 "capability-name": "aai-vf-module-put",
1157 "output-key-mapping": [
1159 "resource-name": "aai-vf-module-put",
1160 "resource-value": ""
1167 "capability-name": "unresolved-composite-data",
1170 "output-key-mapping": [
1172 "resource-name": "vpg_name_0",
1173 "resource-value": "${vf_module_name}"
1180 "resource-accumulator-resolved-data": [
1182 "param-name": "vf-module-model-invariant-uuid",
1183 "param-value": "4e2b9975-5214-48b8-861a-5701c09eedfa"
1186 "param-name": "vf-module-model-version",
1187 "param-value": "011b5f61-6524-4789-bd9a-44cfbf321463"
1190 "param-name": "k8s-rb-profile-name",
1191 "param-value": "default"
1194 "param-name": "k8s-rb-profile-namespace",
1195 "param-value": "default"
1199 - name: resource-assignment for vsn
1202 originatorId: SDNC_DG
1203 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
1204 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
1206 blueprintName: vFW_CNF_CDS
1207 blueprintVersion: 1.0.45
1208 actionName: resource-assignment
1211 resource-assignment-request:
1214 resource-assignment-properties:
1215 nfc-naming-code: vsn
1216 k8s-rb-profile-name: default
1217 service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72
1218 vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0
1219 vf-module-model-customization-uuid: 4cac0584-c0d6-42a7-bdb3-29162792e07f
1220 vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718
1221 vf-module-id: 0cbf558f-5a96-4555-b476-7df8163521aa
1222 aic-cloud-region: k8sregionfour
1225 originatorId: SDNC_DG
1226 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
1227 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
1230 blueprintName: vFW_CNF_CDS
1231 blueprintVersion: 1.0.45
1232 actionName: resource-assignment
1236 eventType: EVENT_COMPONENT_EXECUTED
1240 resource-assignment-response:
1244 "capability-data": [
1246 "capability-name": "generate-name",
1249 "output-key-mapping": [
1251 "resource-name": "vf_module_name",
1252 "resource-value": "${vf-module-name}"
1257 "param-name": "VF_MODULE_TYPE",
1258 "param-value": "vfmt"
1261 "param-name": "resource-name",
1262 "param-value": "vf_module_name"
1265 "param-name": "resource-value",
1266 "param-value": "${vf-module-name}"
1269 "param-name": "external-key",
1270 "param-value": "0cbf558f-5a96-4555-b476-7df8163521aa_vf-module-name"
1273 "param-name": "policy-instance-name",
1274 "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP"
1277 "param-name": "naming-type",
1278 "param-value": "VF-MODULE"
1281 "param-name": "VNF_NAME",
1282 "param-value": "k8sregionfour-onap-nf-20200601t073308018z"
1285 "param-name": "VF_MODULE_LABEL",
1286 "param-value": "vsn"
1293 "capability-name": "netbox-ip-assign",
1296 "output-key-mapping": [
1298 "resource-name": "vsn_onap_private_ip_0",
1299 "resource-value": "${vsn_onap_private_ip_0}"
1304 "param-name": "service-instance-id",
1305 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
1308 "param-name": "prefix-id",
1312 "param-name": "vf_module_id",
1313 "param-value": "0cbf558f-5a96-4555-b476-7df8163521aa"
1316 "param-name": "external_key",
1317 "param-value": "0cbf558f-5a96-4555-b476-7df8163521aa-vsn_onap_private_ip_0"
1324 "capability-name": "aai-vf-module-put",
1327 "output-key-mapping": [
1329 "resource-name": "aai-vf-module-put",
1330 "resource-value": ""
1337 "capability-name": "unresolved-composite-data",
1340 "output-key-mapping": [
1342 "resource-name": "vsn_name_0",
1343 "resource-value": "${vf_module_name}"
1350 "resource-accumulator-resolved-data": [
1352 "param-name": "vf-module-model-invariant-uuid",
1353 "param-value": "36f25e1b-199b-4de2-b656-c870d341cf0e"
1356 "param-name": "vf-module-model-version",
1357 "param-value": "0cbf558f-5a96-4555-b476-7df8163521aa"
1360 "param-name": "k8s-rb-profile-name",
1361 "param-value": "default"
1364 "param-name": "k8s-rb-profile-namespace",
1365 "param-value": "default"
1369 - name: resource-assignment for vfw
1372 originatorId: SDNC_DG
1373 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
1374 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
1376 blueprintName: vFW_CNF_CDS
1377 blueprintVersion: 1.0.45
1378 actionName: resource-assignment
1381 resource-assignment-request:
1384 resource-assignment-properties:
1385 nfc-naming-code: vfw
1386 k8s-rb-profile-name: default
1387 service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72
1388 vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0
1389 vf-module-model-customization-uuid: 1e123e43-ba40-4c93-90d7-b9f27407ec03
1390 vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718
1391 vf-module-id: '0de4ed56-8b4c-4a2d-8ce6-85d5e269204f '
1392 aic-cloud-region: k8sregionfour
1395 originatorId: SDNC_DG
1396 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
1397 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
1400 blueprintName: vFW_CNF_CDS
1401 blueprintVersion: 1.0.45
1402 actionName: resource-assignment
1406 eventType: EVENT_COMPONENT_EXECUTED
1410 resource-assignment-response:
1414 "capability-data": [
1416 "capability-name": "generate-name",
1419 "output-key-mapping": [
1421 "resource-name": "vf_module_name",
1422 "resource-value": "${vf-module-name}"
1427 "param-name": "VF_MODULE_TYPE",
1428 "param-value": "vfmt"
1431 "param-name": "resource-name",
1432 "param-value": "vf_module_name"
1435 "param-name": "resource-value",
1436 "param-value": "${vf-module-name}"
1439 "param-name": "external-key",
1440 "param-value": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f _vf-module-name"
1443 "param-name": "policy-instance-name",
1444 "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP"
1447 "param-name": "naming-type",
1448 "param-value": "VF-MODULE"
1451 "param-name": "VNF_NAME",
1452 "param-value": "k8sregionfour-onap-nf-20200601t073308018z"
1455 "param-name": "VF_MODULE_LABEL",
1456 "param-value": "vfw"
1463 "capability-name": "netbox-ip-assign",
1466 "output-key-mapping": [
1468 "resource-name": "vfw_onap_private_ip_0",
1469 "resource-value": "${vfw_onap_private_ip_0}"
1474 "param-name": "service-instance-id",
1475 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
1478 "param-name": "prefix-id",
1482 "param-name": "vf_module_id",
1483 "param-value": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f "
1486 "param-name": "external_key",
1487 "param-value": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f -vfw_onap_private_ip_0"
1494 "capability-name": "aai-vf-module-put",
1497 "output-key-mapping": [
1499 "resource-name": "aai-vf-module-put",
1500 "resource-value": ""
1507 "capability-name": "unresolved-composite-data",
1510 "output-key-mapping": [
1512 "resource-name": "vfw_name_0",
1513 "resource-value": "${vf_module_name}"
1520 "resource-accumulator-resolved-data": [
1522 "param-name": "vf-module-model-invariant-uuid",
1523 "param-value": "9ffda670-3d77-4f6c-a4ad-fb7a09f19817"
1526 "param-name": "vf-module-model-version",
1527 "param-value": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f"
1530 "param-name": "k8s-rb-profile-name",
1531 "param-value": "default"
1534 "param-name": "k8s-rb-profile-namespace",
1535 "param-value": "default"
1544 path: /restconf/config/GENERIC-RESOURCE-API:services/service/8ead0480-cf44-428e-a4c2-0e6ed10f7a72/service-data/vnfs/vnf/93b3350d-ed6f-413b-9cc5-a158c1676eb0/vnf-data/vnf-topology/vnf-parameters-data/param/vf-naming-policy
1549 - name: vf-naming-policy
1550 value: SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP
1551 resource-resolution-data:
1552 capability-name: RA Resolved
1555 Content-Type: application/json
1559 - Verify CBA with UAT
1563 curl -X POST -u ccsdkapps:ccsdkapps -F cba=@my_cba.zip http://<kube-node>:30499/api/v1/uat/verify
1565 where my_cba.zip is the CBA model with uat.yml (generated in spy step) inside Test folder.
1567 This verify call failed for us with above uat.yaml file generated in spy. Issue was not investigated further in the scope of this use case.
1569 Instantiation Overview
1570 ......................
1572 The 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.
1574 .. figure:: files/vFW_CNF_CDS/Instantiation_topology.png
1577 vFW CNF CDS Use Case Runtime interactions.
1579 --------------------------
1580 PART 1 - ONAP Installation
1581 --------------------------
1582 1-1 Deployment components
1583 ~~~~~~~~~~~~~~~~~~~~~~~~~
1585 In order to run the vFW_CNF_CDS use case, we need ONAP Frankfurt Release (or later) and at least following components:
1587 ======================================================= ===========
1588 ONAP Component name Describtion
1589 ------------------------------------------------------- -----------
1590 AAI Required for Inventory Cloud Owner, Customer, Owning Entity, Service, Generic VNF, VF Module
1591 SDC VSP, VF and Service Modeling of the CNF
1592 DMAAP Distribution of the onboarding package including CBA to all ONAP components
1593 SO Requires for Macro Orchestration using the generic building blocks
1594 CDS Resolution of cloud parameters including Helm override parameters for the CNF. Creation of the multicloud/k8s profile for CNF instantion.
1595 SDNC (needs to include netbox and Naming Generation mS) Provides GENERIC-RESOURCE-API for cloud Instantiation orchestration via CDS.
1596 Policy Used to Store Naming Policy
1597 AAF Used for Authentication and Authorization of requests
1598 Portal Required to access SDC.
1599 MSB Exposes multicloud interfaces used by SO.
1600 Multicloud K8S plugin part used to pass SO instantiation requests to external Kubernetes cloud region.
1601 Contrib Chart containing multiple external components. Out of those, we only use Netbox utility in this use-case for IPAM
1602 Robot Optional. Can be used for running automated tasks, like provisioning cloud customer, cloud region, service subscription, etc ..
1603 Shared Cassandra DB Used as a shared storage for ONAP components that rely on Cassandra DB, like AAI
1604 Shared Maria DB Used as a shared storage for ONAP components that rely on Maria DB, like SDNC, and SO
1605 ======================================================= ===========
1610 In order to deploy such an instance, follow the `ONAP Deployment Guide`_
1612 As 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.
1614 **override.yaml** file where enabled: true is set for each component needed in demo (by default all components are disabled).
1649 Then deploy ONAP with Helm with your override file.
1653 helm deploy onap local/onap --namespace onap -f ~/override.yaml
1655 In case redeployment needed `Helm Healer`_ could be a faster and convenient way to redeploy.
1659 helm-healer.sh -n onap -f ~/override.yaml -s /dockerdata-nfs --delete-all
1661 Or redeploy (clean re-deploy also data removed) just wanted components (Helm releases), cds in this example.
1665 helm-healer.sh -f ~/override.yaml -s /dockerdata-nfs/ -n onap -c onap-cds
1667 There 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*.
1673 for comp in {aaf,aai,dmaap,msb,multicloud,policy,portal,sdc,sdnc,so}; do
1674 if ! ./ete-k8s.sh onap health-$comp; then
1675 failed=$failed,$comp
1678 if [ -n "$failed" ]; then
1679 echo "These components failed: $failed"
1682 echo "Healthcheck successful"
1686 And check status of pods, deployments, jobs etc.
1690 kubectl -n onap get pods | grep -vie 'completed' -e 'running'
1691 kubectl -n onap get deploy,sts,jobs
1697 After completing the first part above, we should have a functional ONAP deployment for the Frankfurt Release.
1699 We will need to apply a few modifications to the deployed ONAP Frankfurt instance in order to run the use case.
1701 Retrieving logins and passwords of ONAP components
1702 ..................................................
1704 Since 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.
1708 kubectl get secret `kubectl get secrets | grep mariadb-galera-db-root-password | awk {'print $1'}` -o jsonpath="{.data.login}" | base64 --decode
1709 kubectl get secret `kubectl get secrets | grep mariadb-galera-db-root-password | awk {'print $1'}` -o jsonpath="{.data.password}" | base64 --decode
1711 In this case login is empty as the secret is dedicated to root user.
1713 Postman collection setup
1714 ........................
1716 In 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. Later when this demo is fully automated we probably update also Robot scripts to support this demo.
1718 Postman collection is used also to trigger instantiation using SO APIs.
1720 Following steps are needed to setup Postman:
1722 - Import this Postman collection zip
1724 :download:`Postman collection <files/vFW_CNF_CDS/postman.zip>`
1726 - 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.
1727 - `vFW_CNF_CDS.postman_collection.json`
1728 - `vFW_CNF_CDS.postman_environment.json`
1730 - 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.
1734 kubectl -n onap edit svc so-catalog-db-adapter
1735 - .spec.type: ClusterIP
1736 + .spec.type: NodePort
1737 + .spec.ports[0].nodePort: 30120
1739 .. note:: The port number 30120 is used in included Postman collection
1741 - 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:
1745 kubectl edit -n onap svc cds-blueprints-processor-http
1746 - .spec.type: ClusterIP
1747 + .spec.type: NodePort
1748 + .spec.ports[0].nodePort: 30499
1750 .. note:: The port number 30499 is used in included Postman collection
1752 **Postman variables:**
1754 Most of the Postman variables are automated by Postman scripts and environment file provided, but there are few mandatory variables to fill by user.
1756 ===================== ===================
1757 Variable Description
1758 --------------------- -------------------
1759 k8s ONAP Kubernetes host
1760 sdnc_port port of sdnc service for accessing MDSAL
1761 service-name name of service as defined in SDC
1762 service-version version of service defined in SDC (if service wasn't updated, it should be set to "1.0")
1763 service-instance-name name of instantiated service (if ending with -{num}, will be autoincremented for each instantiation request)
1764 ===================== ===================
1766 You can get the sdnc_port value with
1770 kubectl -n onap get svc sdnc -o json | jq '.spec.ports[]|select(.port==8282).nodePort'
1776 Some 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.
1778 Create all these entries into AAI in this order. Postman collection provided in this demo can be used for creating each entry.
1780 **Postman -> Initial ONAP setup -> Create**
1783 - Create Owning-entity
1786 - Create Line Of Business
1788 Corresponding 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.
1790 SO BPMN endpoint fix for VNF adapter requests (v1 -> v2)
1791 ........................................................
1793 SO Openstack adapter needs to be updated to use newer version. Here is also possible improvement area in SO. OpenStack adapter is confusing in context of this use case as VIM is not Openstack but Kubernetes cloud region. In this use case we did not used Openstack at all.
1797 kubectl -n onap edit configmap onap-so-bpmn-infra-app-configmap
1798 - .data."override.yaml".mso.adapters.vnf.rest.endpoint: http://so-openstack-adapter.onap:8087/services/rest/v1/vnfs
1799 + .data."override.yaml".mso.adapters.vnf.rest.endpoint: http://so-openstack-adapter.onap:8087/services/rest/v2/vnfs
1800 kubectl -n onap delete pod -l app=so-bpmn-infra
1805 Naming 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.
1807 This usecase leverages default ONAP naming policy - "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP".
1808 To check that the naming policy is created and pushed OK, we can run the command below from inside any ONAP pod.
1812 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"
1814 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
1819 FIXME - Verify if on RC2 this still needs to be performed
1821 There's a strange feature or bug in naming service still at ONAP Frankfurt and following hack needs to be done to make it work.
1823 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
1827 # Go into naming service database
1828 kubectl -n onap exec onap-mariadb-galera-0 -it -- mysql -uroot -psecretpassword -D nengdb
1829 select * from EXTERNAL_INTERFACE;
1830 # Delete entries from EXTERNAL_INTERFACE table
1831 delete from EXTERNAL_INTERFACE;
1832 select * from EXTERNAL_INTERFACE;
1834 ---------------------------------------------------
1835 PART 2 - Installation of managed Kubernetes cluster
1836 ---------------------------------------------------
1838 In 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.
1840 2-1 Installation of Managed Kubernetes
1841 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1843 In this demo we use Kubernetes deployment used by ONAP multicloud/k8s team to test their plugin features see `KUD readthedocs`_. There's also some outdated instructions in ONAP wiki `KUD in Wiki`_.
1845 KUD 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.
1847 See `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:
1853 Follow instructions in `KUD readthedocs`_ 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.
1855 2-2 Cloud Registration
1856 ~~~~~~~~~~~~~~~~~~~~~~
1858 Managed 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.
1860 Postman collection have folder/entry for each step. Execute in this order.
1862 **Postman -> K8s Cloud Region Registration -> Create**
1865 - Create Cloud Region
1866 - Create Complex-Cloud Region Relationship
1868 - Create Service Subscription
1869 - Create Cloud Tenant
1870 - Create Availability Zone
1871 - Upload Connectivity Info
1873 .. 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 directory `~/.kube/config` and can be easily retrieved e.g. via SCP. Please ensure that kubeconfig contains external IP of K8s cluster in kubeconfig and correct it, if it's not.
1875 **SO Cloud region configuration**
1877 SO 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.
1879 The related code part in SO is here: `SO Cloud Region Selection`_
1880 It's possible improvement place in SO to rather get this information directly from AAI.
1882 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
1886 kubectl -n onap exec onap-mariadb-galera-0 -it -- mysql -uroot -psecretpassword -D catalogdb
1887 select * from cloud_sites;
1888 insert into cloud_sites(ID, REGION_ID, IDENTITY_SERVICE_ID, CLOUD_VERSION, CLLI, ORCHESTRATOR) values("k8sregionfour", "k8sregionfour", "DEFAULT_KEYSTONE", "2.5", "clli2", "multicloud");
1889 select * from cloud_sites;
1892 ----------------------------------
1893 PART 3 - Execution of the Use Case
1894 ----------------------------------
1896 This part contains all the steps to run the use case by using ONAP GUIs and Postman.
1898 Following picture describes the overall sequential flow of the use case.
1900 .. figure:: files/vFW_CNF_CDS/vFW_CNF_CDS_Flow.png
1903 vFW CNF CDS Use Case sequence flow.
1908 Creating Onboarding Package
1909 ...........................
1911 Whole content of this use case is stored into single git repository and ONAP user content package of onboarding package can be created with provided Makefile.
1913 Complete content can be packaged to single onboarding package file in the following way:
1915 .. note:: Requires Helm installed
1919 git clone https://gerrit.onap.org/r/demo
1920 cd heat/vFW_CNF_CDS/templates
1923 The output looks like:
1928 make[1]: Entering directory '/home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm'
1929 rm -f base_template-*.tgz
1930 rm -f base_template_cloudtech_k8s_charts.tgz
1931 helm package base_template
1932 Successfully packaged chart and saved it to: /home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm/base_template-0.2.0.tgz
1933 mv base_template-*.tgz base_template_cloudtech_k8s_charts.tgz
1935 rm -f vpkg_cloudtech_k8s_charts.tgz
1937 Successfully packaged chart and saved it to: /home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm/vpkg-0.2.0.tgz
1938 mv vpkg-*.tgz vpkg_cloudtech_k8s_charts.tgz
1940 rm -f vfw_cloudtech_k8s_charts.tgz
1942 Successfully packaged chart and saved it to: /home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm/vfw-0.2.0.tgz
1943 mv vfw-*.tgz vfw_cloudtech_k8s_charts.tgz
1945 rm -f vsn_cloudtech_k8s_charts.tgz
1947 Successfully packaged chart and saved it to: /home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm/vsn-0.2.0.tgz
1948 mv vsn-*.tgz vsn_cloudtech_k8s_charts.tgz
1949 make[1]: Leaving directory '/home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm'
1950 mv helm/*.tgz package/
1952 cd cba/ && zip -r vFW_CDS_CNF.zip .
1953 adding: TOSCA-Metadata/ (stored 0%)
1954 adding: TOSCA-Metadata/TOSCA.meta (deflated 38%)
1955 adding: Templates/ (stored 0%)
1956 adding: Templates/base_template-mapping.json (deflated 92%)
1957 adding: Templates/vfw-template.vtl (deflated 87%)
1958 adding: Templates/nf-params-mapping.json (deflated 86%)
1959 adding: Templates/vsn-mapping.json (deflated 94%)
1960 adding: Templates/vnf-template.vtl (deflated 90%)
1961 adding: Templates/vpkg-mapping.json (deflated 94%)
1962 adding: Templates/vsn-template.vtl (deflated 87%)
1963 adding: Templates/nf-params-template.vtl (deflated 44%)
1964 adding: Templates/base_template-template.vtl (deflated 85%)
1965 adding: Templates/vfw-mapping.json (deflated 94%)
1966 adding: Templates/vnf-mapping.json (deflated 92%)
1967 adding: Templates/vpkg-template.vtl (deflated 86%)
1968 adding: Templates/k8s-profiles/ (stored 0%)
1969 adding: Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz (stored 0%)
1970 adding: Scripts/ (stored 0%)
1971 adding: Scripts/kotlin/ (stored 0%)
1972 adding: Scripts/kotlin/KotlinK8sProfileUpload.kt (deflated 75%)
1973 adding: Scripts/kotlin/README.md (stored 0%)
1974 adding: Definitions/ (stored 0%)
1975 adding: Definitions/artifact_types.json (deflated 57%)
1976 adding: Definitions/vFW_CNF_CDS.json (deflated 81%)
1977 adding: Definitions/node_types.json (deflated 86%)
1978 adding: Definitions/policy_types.json (stored 0%)
1979 adding: Definitions/data_types.json (deflated 93%)
1980 adding: Definitions/resources_definition_types.json (deflated 95%)
1981 adding: Definitions/relationship_types.json (stored 0%)
1982 mv cba/vFW_CDS_CNF.zip package/
1983 #Can't use .package extension or SDC will panic
1984 cd package/ && zip -r vfw_k8s_demo.zip .
1985 adding: base_template_cloudtech_k8s_charts.tgz (stored 0%)
1986 adding: MANIFEST.json (deflated 83%)
1987 adding: base_template.yaml (deflated 63%)
1988 adding: vsn_cloudtech_k8s_charts.tgz (stored 0%)
1989 adding: vfw_cloudtech_k8s_charts.tgz (stored 0%)
1990 adding: vpkg_cloudtech_k8s_charts.tgz (stored 0%)
1991 adding: vsn.yaml (deflated 75%)
1992 adding: vpkg.yaml (deflated 76%)
1993 adding: vfw.yaml (deflated 77%)
1994 adding: vFW_CDS_CNF.zip (stored 0%)
1995 adding: base_template.env (deflated 23%)
1996 adding: vsn.env (deflated 53%)
1997 adding: vpkg.env (deflated 55%)
1998 adding: vfw.env (deflated 58%)
1999 mv package/vfw_k8s_demo.zip .
2002 and package **vfw_k8s_demo.zip** file is created containing all sub-models.
2004 Import this package into SDC and follow onboarding steps.
2006 Service Creation with SDC
2007 .........................
2009 Service 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`_
2012 - Remember during VSP onboard to choose "Network Package" Onboarding procedure
2014 Create VF and Service
2015 Service -> Properties Assignment -> Choose VF (at right box):
2016 - skip_post_instantiation_configuration - True
2017 - sdnc_artifact_name - vnf
2018 - sdnc_model_name - vFW_CNF_CDS
2019 - sdnc_model_version - K8s 1.0.45
2021 Distribution Of Service
2022 .......................
2026 Verify 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:
2030 SDC Catalog database should have our service now defined.
2032 **Postman -> LCM -> [SDC] Catalog Service**
2037 "uuid": "64dd38f3-2307-4e0a-bc98-5c2cbfb260b6",
2038 "invariantUUID": "cd1a5c2d-2d4e-4d62-ac10-a5fe05e32a22",
2039 "name": "vfw_cnf_cds_svc",
2041 "toscaModelURL": "/sdc/v1/catalog/services/64dd38f3-2307-4e0a-bc98-5c2cbfb260b6/toscaModel",
2042 "category": "Network L4+",
2043 "lifecycleState": "CERTIFIED",
2044 "lastUpdaterUserId": "cs0008",
2045 "distributionStatus": "DISTRIBUTED"
2049 Listing should contain entry with our service name **vfw_cnf_cds_svc**.
2051 .. 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.
2055 SO Catalog database should have our service NFs defined now.
2057 **Postman -> LCM -> [SO] Catalog DB Service xNFs**
2065 "modelName": "vfw_cnf_cds_vsp",
2066 "modelUuid": "70edaca8-8c79-468a-aa76-8224cfe686d0",
2067 "modelInvariantUuid": "7901fc89-a94d-434a-8454-1e27b99dc0e2",
2068 "modelVersion": "1.0",
2069 "modelCustomizationUuid": "86dc8af4-aa17-4fc7-9b20-f12160d99718",
2070 "modelInstanceName": "vfw_cnf_cds_vsp 0"
2072 "toscaNodeType": "org.openecomp.resource.vf.VfwCnfCdsVsp",
2076 "nfNamingCode": null,
2077 "multiStageDesign": "false",
2078 "vnfcInstGroupOrder": null,
2079 "resourceInput": "TBD",
2083 "modelName": "VfwCnfCdsVsp..base_template..module-0",
2084 "modelUuid": "274f4bc9-7679-4767-b34d-1df51cdf2496",
2085 "modelInvariantUuid": "52842255-b7be-4a1c-ab3b-2bd3bd4a5423",
2086 "modelVersion": "1",
2087 "modelCustomizationUuid": "b27fad11-44da-4840-9256-7ed8a32fbe3e"
2090 "vfModuleLabel": "base_template",
2092 "hasVolumeGroup": false
2096 "modelName": "VfwCnfCdsVsp..vsn..module-1",
2097 "modelUuid": "0cbf558f-5a96-4555-b476-7df8163521aa",
2098 "modelInvariantUuid": "36f25e1b-199b-4de2-b656-c870d341cf0e",
2099 "modelVersion": "1",
2100 "modelCustomizationUuid": "4cac0584-c0d6-42a7-bdb3-29162792e07f"
2103 "vfModuleLabel": "vsn",
2105 "hasVolumeGroup": false
2109 "modelName": "VfwCnfCdsVsp..vpkg..module-2",
2110 "modelUuid": "011b5f61-6524-4789-bd9a-44cfbf321463",
2111 "modelInvariantUuid": "4e2b9975-5214-48b8-861a-5701c09eedfa",
2112 "modelVersion": "1",
2113 "modelCustomizationUuid": "4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb"
2116 "vfModuleLabel": "vpkg",
2118 "hasVolumeGroup": false
2122 "modelName": "VfwCnfCdsVsp..vfw..module-3",
2123 "modelUuid": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f",
2124 "modelInvariantUuid": "9ffda670-3d77-4f6c-a4ad-fb7a09f19817",
2125 "modelVersion": "1",
2126 "modelCustomizationUuid": "1e123e43-ba40-4c93-90d7-b9f27407ec03"
2129 "vfModuleLabel": "vfw",
2131 "hasVolumeGroup": false
2141 SDNC should have it's database updated with sdnc_* properties that were set during service modeling.
2143 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
2147 kubectl -n onap exec onap-mariadb-galera-0 -it -- sh
2148 mysql -uroot -psecretpassword -D sdnctl
2149 MariaDB [sdnctl]> select sdnc_model_name, sdnc_model_version, sdnc_artifact_name from VF_MODEL WHERE customization_uuid = '86dc8af4-aa17-4fc7-9b20-f12160d99718';
2150 +-----------------+--------------------+--------------------+
2151 | sdnc_model_name | sdnc_model_version | sdnc_artifact_name |
2152 +-----------------+--------------------+--------------------+
2153 | vFW_CNF_CDS | 1.0.45 | vnf |
2154 +-----------------+--------------------+--------------------+
2155 1 row in set (0.00 sec)
2158 .. note:: customization_uuid value is the modelCustomizationUuid of the VNF (serviceVnfs response in 2nd Postman call from SO Catalog DB)
2162 CDS should onboard CBA uploaded as part of VF.
2164 **Postman -> Distribution Verification -> [CDS] List CBAs**
2171 "id": "c505e516-b35d-4181-b1e2-bcba361cfd0a",
2172 "artifactUUId": null,
2173 "artifactType": "SDNC_MODEL",
2174 "artifactVersion": "1.0.45",
2175 "artifactDescription": "Controller Blueprint for vFW_CNF_CDS:1.0.45",
2176 "internalVersion": null,
2177 "createdDate": "2020-05-29T06:02:20.000Z",
2178 "artifactName": "vFW_CNF_CDS",
2180 "updatedBy": "Samuli Silvius <s.silvius@partner.samsung.com>",
2181 "tags": "Samuli Silvius, vFW_CNF_CDS"
2186 The list should have the matching entries with SDNC database:
2188 - sdnc_model_name == artifactName
2189 - sdnc_model_version == artifactVersion
2191 You can also use **Postman -> Distribution Verification -> [CDS] CBA Download** to download CBA for further verification but it's fully optional.
2195 K8splugin should onboard 4 resource bundles related to helm resources:
2197 **Postman -> Distribution Verification -> [K8splugin] List Resource Bundle Definitions**
2203 "rb-name": "52842255-b7be-4a1c-ab3b-2bd3bd4a5423",
2204 "rb-version": "274f4bc9-7679-4767-b34d-1df51cdf2496",
2205 "chart-name": "base_template",
2208 "vnf_customization_uuid": "b27fad11-44da-4840-9256-7ed8a32fbe3e"
2212 "rb-name": "36f25e1b-199b-4de2-b656-c870d341cf0e",
2213 "rb-version": "0cbf558f-5a96-4555-b476-7df8163521aa",
2214 "chart-name": "vsn",
2217 "vnf_customization_uuid": "4cac0584-c0d6-42a7-bdb3-29162792e07f"
2221 "rb-name": "4e2b9975-5214-48b8-861a-5701c09eedfa",
2222 "rb-version": "011b5f61-6524-4789-bd9a-44cfbf321463",
2223 "chart-name": "vpkg",
2226 "vnf_customization_uuid": "4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb"
2230 "rb-name": "9ffda670-3d77-4f6c-a4ad-fb7a09f19817",
2231 "rb-version": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f",
2232 "chart-name": "vfw",
2235 "vnf_customization_uuid": "1e123e43-ba40-4c93-90d7-b9f27407ec03"
2240 3-2 CNF Instantiation
2241 ~~~~~~~~~~~~~~~~~~~~~
2243 This 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.
2245 Use again Postman to trigger instantion from SO interface. Postman 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:
2247 - **Postman -> LCM -> 1.[SDC] Catalog Service**
2248 - **Postman -> LCM -> 2. [SO] Catalog DB Service xNFs**
2250 Now actual instantiation can be triggered with:
2252 **Postman -> LCM -> 3. [SO] Self-Serve Service Assign & Activate**
2254 Follow progress with SO's GET request:
2256 **Postman -> LCM -> 4. [SO] Infra Active Requests**
2258 The successful reply payload in that query should start like this:
2263 "clientRequestId": null,
2264 "action": "createInstance",
2265 "requestStatus": "COMPLETED",
2266 "statusMessage": "Failed to create self-serve assignment for vf-module with vf-module-id=b70112fd-f6b2-44fe-a55c-6928d61843bf with error: Encountered error from self-serve-generate-name with error: Error from NameGenerationNode Assign",
2267 "rollbackStatusMessage": null,
2268 "flowStatus": "Execution of UnassignVfModuleBB has completed successfully, next invoking UnassignVfModuleBB (Execution Path progress: BBs completed = 1; BBs remaining = 4).",
2269 "retryStatusMessage": null,
2272 **FIXME: provide full COMPLETED payload**
2274 Progress can be followed also with `SO Monitoring`_ dashboard.
2276 .. note:: In Frankfurt release *SO Monitoring* dashboard was removed from officail release and before it can be used it must be exposed and default user credentials must be configured
2279 You can finally terminate this instance (now or later) with another call:
2281 **Postman -> LCM -> 5. [SO] Service Delete**
2283 Second instance Instantion
2284 ..........................
2286 To finally verify that all the work done within this demo, it should be possible to instantiate second vFW instance successfully.
2288 Trigger new instance createion. You can use previous call or a separate one that will utilize profile templating mechanism implemented in CBA:
2290 **Postman -> LCM -> 6. [SO] Self-Serve Service Assign & Activate - Second**
2292 3-3 Results and Logs
2293 ~~~~~~~~~~~~~~~~~~~~
2295 Now multiple instances of Kubernetes variant of vFW are running in target VIM (KUD deployment).
2297 .. figure:: files/vFW_CNF_CDS/vFW_Instance_In_Kubernetes.png
2300 vFW Instance In Kubernetes
2302 To 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.
2304 **Postman -> Instantiation verification**
2306 Execute example Postman queries and check example section to see the valid results.
2308 ========================== =================
2309 Verify Target Postman query
2310 -------------------------- -----------------
2311 Service Instances in AAI **Postman -> Instantiation verification -> [AAI] List Service Instances**
2312 Service Instances in MDSAL **Postman -> Instantiation verification -> [SDNC] GR-API MD-SAL Services**
2313 K8S Instances in KUD **Postman -> Instantiation verification -> [K8splugin] List Instances**
2314 ========================== =================
2316 .. note:: "[AAI] List vServers <Empty>" Request won't return any vserver info from AAI, as currently such information are not provided during instantiation process.
2319 Query also directly from VIM:
2321 FIXME - needs updated output with newest naming policy
2326 ubuntu@kud-host:~$ kubectl get pods,svc,networks,cm,network-attachment-definition,deployments
2327 NAME READY STATUS RESTARTS AGE
2328 pod/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f-7cfb9949d9-8b5vg 1/1 Running 0 22s
2329 pod/vfw-19571429-4af4-49b3-af65-2eb1f97bba43-75cd7c6f76-4gqtz 1/1 Running 0 11m
2330 pod/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-f4485d485-pln8m 1/1 Running 0 11m
2331 pod/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-6f8cff54d-dvw4j 1/1 Running 0 32s
2332 pod/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-5879c56fd-q59l7 2/2 Running 0 11m
2333 pod/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-5889b7455-96j9d 2/2 Running 0 30s
2335 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
2336 service/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-management-api NodePort 10.244.43.245 <none> 2831:30831/TCP 11m
2337 service/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-management-api NodePort 10.244.1.45 <none> 2831:31831/TCP 33s
2338 service/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-darkstat-ui NodePort 10.244.16.187 <none> 667:30667/TCP 11m
2339 service/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-darkstat-ui NodePort 10.244.20.229 <none> 667:31667/TCP 30s
2342 network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-management-network 40s
2343 network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-protected-network 40s
2344 network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-unprotected-network 40s
2345 network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-management-network 11m
2346 network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-protected-network 11m
2347 network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-unprotected-network 11m
2350 configmap/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f-configmap 6 22s
2351 configmap/vfw-19571429-4af4-49b3-af65-2eb1f97bba43-configmap 6 11m
2352 configmap/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-configmap 6 11m
2353 configmap/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-configmap 6 33s
2354 configmap/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-configmap 2 11m
2355 configmap/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-configmap 2 30s
2358 networkattachmentdefinition.k8s.cni.cncf.io/55118b80-8470-4c99-bfdf-d122cd412739-ovn-nat 40s
2359 networkattachmentdefinition.k8s.cni.cncf.io/567cecc3-9692-449e-877a-ff0b560736be-ovn-nat 11m
2361 NAME READY UP-TO-DATE AVAILABLE AGE
2362 deployment.extensions/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f 1/1 1 1 22s
2363 deployment.extensions/vfw-19571429-4af4-49b3-af65-2eb1f97bba43 1/1 1 1 11m
2364 deployment.extensions/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e 1/1 1 1 11m
2365 deployment.extensions/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26 1/1 1 1 33s
2366 deployment.extensions/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14 1/1 1 1 11m
2367 deployment.extensions/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b 1/1 1 1 30s
2370 Component Logs From The Execution
2371 .................................
2373 All logs from the use case execution are here:
2375 :download:`logs <files/vFW_CNF_CDS/logs.zip>`
2377 - `so-bpmn-infra_so-bpmn-infra_debug.log`
2378 - SO openstack adapter
2379 - `sdnc_sdnc_karaf.log`
2381 From karaf.log all requests (payloads) to CDS can be found by searching following string:
2383 ``'Sending request below to url http://cds-blueprints-processor-http:8080/api/v1/execution-service/process'``
2385 - `cds-blueprints-processor_cds-blueprints-processor_POD_LOG.log`
2386 - `multicloud-k8s_multicloud-k8s_POD_LOG.log`
2392 In case more detailed logging is needed, here's instructions how to setup DEBUG logging for few components.
2398 kubectl -n onap exec -it onap-sdnc-0 -c sdnc /opt/opendaylight/bin/client log:set DEBUG
2401 - CDS Blueprint Processor
2406 kubectl -n onap edit configmap onap-cds-blueprints-processor-configmap
2408 # Edit logback.xml content change root logger level from info to debug.
2409 <root level="debug">
2410 <appender-ref ref="STDOUT"/>
2413 # Delete the Pods to make changes effective
2414 kubectl -n onap delete pods -l app=cds-blueprints-processor
2416 -----------------------------------------------
2417 PART 4 - Summary and Future improvements needed
2418 -----------------------------------------------
2420 This use case made CNFs onboarding and instantiation a little bit easier and closer to "normal" VNF way. Also CDS resource resolution capabilities were taken into use (compared to earlier demos) together with SO's MACRO workflow.
2422 CNF application in vFW (Helm charts) were divided to multiple Helm charts comply with vf-module structure of a Heat based VNF.
2424 Future development areas for this use case and in general for CNF support could be:
2426 - Automate manual initialization steps in to Robot init. Now all was done with Postman or manual step on command line.
2427 - Automate use case in ONAP daily CI
2428 - Include Closed Loop part of the vFW demo.
2429 - Use multicloud/k8S API v2. Also consider profile concept future.
2430 - Sync CDS model with `vFW_CNF_CDS Model`_ use case i.e. try to keep only single model regardless of xNF being Openstack or Kubernetes based.
2431 - TOSCA based service and xNF models instead of dummy Heat wrapper. Won't work directly with current vf-module oriented SO workflows.
2432 - vFW service with Openstack VNF and Kubernetes CNF
2433 - Post instantiation configuration with Day 2 configuration APIs of multicloud/k8S API
2434 - Auto generation of instantiation specific helm resources in CDS and their population through profiles
2437 Multiple lower level bugs/issues were also found during use case development
2439 - Distribution of Helm package directly from onboarding package `SDC-2776`_
2440 - CDS: UAT testing is broken `CCSDK-2155`_
2442 .. _ONAP Deployment Guide: https://docs.onap.org/en/frankfurt/submodules/oom.git/docs/oom_quickstart_guide.html#quick-start-label
2443 .. _CDS Modeling Concepts: https://wiki.onap.org/display/DW/Modeling+Concepts
2444 .. _vLB use-case: https://wiki.onap.org/pages/viewpage.action?pageId=71838898
2445 .. _vFW_CNF_CDS Model: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS?h=frankfurt
2446 .. _vFW CDS Dublin: https://wiki.onap.org/display/DW/vFW+CDS+Dublin
2447 .. _vFW CBA Model: https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/service-blueprint/vFW?h=frankfurt
2448 .. _vFW_Helm Model: https://git.onap.org/multicloud/k8s/tree/kud/demo/firewall?h=elalto
2449 .. _vFW_NextGen: https://git.onap.org/demo/tree/heat/vFW_NextGen?h=elalto
2450 .. _vFW EDGEX K8S: https://onap.readthedocs.io/en/elalto/submodules/integration.git/docs/docs_vfw_edgex_k8s.html
2451 .. _vFW EDGEX K8S In ONAP Wiki: https://wiki.onap.org/display/DW/Deploying+vFw+and+EdgeXFoundry+Services+on+Kubernets+Cluster+with+ONAP
2452 .. _KUD readthedocs: https://docs.onap.org/en/frankfurt/submodules/multicloud/k8s.git/docs
2453 .. _KUD in Wiki: https://wiki.onap.org/display/DW/Kubernetes+Baremetal+deployment+setup+instructions
2454 .. _Multicloud k8s gerrit: https://gerrit.onap.org/r/q/status:open+project:+multicloud/k8
2455 .. _KUD subproject in github: https://github.com/onap/multicloud-k8s/tree/master/kud
2456 .. _KUD Jenkins ci/cd verification: https://jenkins.onap.org/job/multicloud-k8s-master-kud-deployment-verify-shell/
2457 .. _SO Cloud Region Selection: https://git.onap.org/so/tree/adapters/mso-openstack-adapters/src/main/java/org/onap/so/adapters/vnf/MsoVnfPluginAdapterImpl.java?h=elalto#n1149
2458 .. _SO Monitoring: https://wiki.onap.org/display/DW/SO+Monitoring+User+Guide
2459 .. _Jira Epic: https://jira.onap.org/browse/INT-1184
2460 .. _Data Dictionary: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba-dd.json?h=frankfurt
2461 .. _Helm Healer: https://git.onap.org/oom/offline-installer/tree/tools/helm-healer.sh
2462 .. _CDS UAT Testing: https://wiki.onap.org/display/DW/Modeling+Concepts
2463 .. _postman.zip: files/vFW_CNF_CDS/postman.zip
2464 .. _logs.zip: files/vFW_CNF_CDS/logs.zip
2465 .. _SDC-2776: https://jira.onap.org/browse/SDC-2776
2466 .. _MULTICLOUD-941: https://jira.onap.org/browse/MULTICLOUD-941
2467 .. _CCSDK-2155: https://jira.onap.org/browse/CCSDK-2155
2468 .. _infra_workload: https://docs.onap.org/en/latest/submodules/multicloud/framework.git/docs/specs/multicloud_infra_workload.html
2469 .. _SDNC-1116: https://jira.onap.org/browse/SDNC-1116
2470 .. _SO-2727: https://jira.onap.org/browse/SO-2727
2471 .. _SDNC-1109: https://jira.onap.org/browse/SDNC-1109
2472 .. _SDC-2776: https://jira.onap.org/browse/SDC-2776
2473 .. _INT-1255: https://jira.onap.org/browse/INT-1255
2474 .. _SDNC-1130: https://jira.onap.org/browse/SDNC-1130