1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
2 .. http://creativecommons.org/licenses/by/4.0
10 ----------------------
14 - Heat/Helm/CDS models: `vFW_CNF_CDS Model`_
18 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`_.
20 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.
22 Following improvements were made in the Use Case or related ONAP components:
24 - Changed vFW Kubernetes Helm charts to support overrides (previously mostly hardcoded values)
25 - Combined all models (Heat, Helm, CBA) in to same git repo and a creating single onboarding package `vFW_CNF_CDS Model`_
26 - 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)
27 - SDC accepts Onboarding Package with many helm packages what allows to keep decomposition of service instance similar to `vFW CDS Dublin`_
28 - CDS is used to resolve instantiation time parameters (Helm override)
29 - Ip addresses with IPAM
30 - Unique names for resources with ONAP naming service
31 - Multicloud/k8s plugin changed to support identifiers of vf-module concept
32 - **multicloud/k8s** creates automatically default empty RB profile and profile upload becomes optional for instantiation of CNF
33 - CDS is used to create **multicloud/k8s profile** as part of instantiation flow (previously manual step)
35 Use case does not contain Closed Loop part of the vFW demo.
39 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.
41 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.
43 Demo git directory has also `Data Dictionary`_ file (CDS model time resource) included.
45 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.
47 Following table describes all the source models to which this demo is based on.
49 =============== ================= ===========
50 Model Git reference Description
51 --------------- ----------------- -----------
52 Heat `vFW_NextGen`_ Heat templates used in original vFW demo but split into multiple vf-modules
53 Helm `vFW_Helm Model`_ Helm templates used in `vFW EDGEX K8S`_ demo
54 CDS model `vFW CBA Model`_ CDS CBA model used in `vFW CDS Dublin`_ demo
55 =============== ================= ===========
57 All changes to related ONAP components and Use Case can be found from this `Jira Epic`_ ticket.
59 Modeling Onboarding Package/Helm
60 ................................
62 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.
64 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.
66 CDS model (CBA package) is delivered as SDC supported own type CONTROLLER_BLUEPRINT_ARCHIVE.
71 "name": "virtualFirewall",
75 "file": "vFW_CDS_CNF.zip",
76 "type": "CONTROLLER_BLUEPRINT_ARCHIVE"
79 "file": "base_template.yaml",
84 "file": "base_template.env",
90 "file": "base_template_cloudtech_k8s_charts.tgz",
91 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
105 "file": "vfw_cloudtech_k8s_charts.tgz",
106 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
120 "file": "vpkg_cloudtech_k8s_charts.tgz",
121 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
135 "file": "vsn_cloudtech_k8s_charts.tgz",
136 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
144 K8s plugin was changed to support new way to identify k8s application and related multicloud/k8s profile.
148 - SDC distribution broker
150 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.
152 - K8S plugin APIs changed to use VF Module Model Identifiers
154 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.
156 **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`_
157 Note that API endpoints are not changed but only the semantics.
165 /api/multicloud-k8s/v1/v1/rb/definition/{VF Module Model Invariant ID}/{VF Module Model Version ID}/content
172 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
173 { "rb-name": “{VF Module Model Invariant ID}",
174 "rb-version": "{VF Module Model Version ID}",
175 "profile-name": "p1",
176 "release-name": "r1",
177 "namespace": "testns1",
178 "kubernetes-version": "1.13.5"
181 Upload Profile content API
185 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
187 - Instantiation broker
189 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).
192 For helm package instantiation following parameters have to be delivered in the SDNC directives:
195 ======================== ==============================================
199 ------------------------ ----------------------------------------------
201 k8s-rb-profile-name Name of the override profile
203 k8s-rb-profile-namespace Name of the namespace for created helm package
205 ======================== ==============================================
207 - Default profile support was added to the plugin
209 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**
211 - Instantiation time override support was added to the plugin
213 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.
219 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.
221 - 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.
222 - 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.
223 - Our little experience of CDS (not CDS developers)
225 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`_.
227 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.
229 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.
234 "base_template-template" : {
235 "type" : "artifact-template-velocity",
236 "file" : "Templates/base_template-template.vtl"
238 "base_template-mapping" : {
239 "type" : "artifact-mapping-resource",
240 "file" : "Templates/base_template-mapping.json"
243 "type" : "artifact-template-velocity",
244 "file" : "Templates/vpkg-template.vtl"
247 "type" : "artifact-mapping-resource",
248 "file" : "Templates/vpkg-mapping.json"
251 "type" : "artifact-template-velocity",
252 "file" : "Templates/vfw-template.vtl"
255 "type" : "artifact-mapping-resource",
256 "file" : "Templates/vfw-mapping.json"
259 "type" : "artifact-template-velocity",
260 "file" : "Templates/vnf-template.vtl"
263 "type" : "artifact-mapping-resource",
264 "file" : "Templates/vnf-mapping.json"
267 "type" : "artifact-template-velocity",
268 "file" : "Templates/vsn-template.vtl"
271 "type" : "artifact-mapping-resource",
272 "file" : "Templates/vsn-mapping.json"
276 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.
278 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.
279 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
280 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.
287 values: “override_values.yaml”
289 - filepath: resources/deployment.yaml
290 chartpath: templates/deployment.yaml
293 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
294 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.
296 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.
300 "resource-assignment": {
302 "resource-assignment": {
303 "description": "Resource Assign Workflow",
304 "target": "resource-assignment",
307 "call_operation": "ResourceResolutionComponent.process"
311 "profile-modification"
314 "profile-modification": {
315 "description": "Profile Modification Resources",
316 "target": "profile-modification",
319 "call_operation": "ResourceResolutionComponent.process"
327 "description": "Upload K8s Profile",
328 "target": "profile-upload",
331 "call_operation": "ComponentScriptExecutor.process"
337 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.
344 name: {{ .Values.vpg_name_0 }}-ssh-access
346 vnf-name: {{ .Values.vnf_name }}
347 vf-module-name: {{ .Values.vpg_name_0 }}
348 release: {{ .Release.Name }}
349 chart: {{ .Chart.Name }}
354 nodePort: ${vpg-management-port}
356 vf-module-name: {{ .Values.vpg_name_0 }}
357 release: {{ .Release.Name }}
358 chart: {{ .Chart.Name }}
360 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.
361 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
366 "profile-modification": {
367 "type": "component-resource-resolution",
369 "ResourceResolutionComponent": {
373 "artifact-prefix-names": [
382 "ssh-service-template": {
383 "type": "artifact-template-velocity",
384 "file": "Templates/k8s-profiles/ssh-service-template.vtl"
386 "ssh-service-mapping": {
387 "type": "artifact-mapping-resource",
388 "file": "Templates/k8s-profiles/ssh-service-mapping.json"
393 "type": "component-script-executor",
395 "ComponentScriptExecutor": {
399 "script-type": "kotlin",
400 "script-class-reference": "org.onap.ccsdk.cds.blueprintsprocessor.services.execution.scripts.K8sProfileUpload",
401 "dynamic-properties": "*profile-upload-properties"
409 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**.
411 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.
417 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.
419 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).
421 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.
423 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.
425 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).
427 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.
429 To verify CBA with uat.yaml and CDS runtime do following:
431 - Enable UAT testing for CDS runtime
435 kubectl -n onap edit deployment onap-cds-blueprints-processor
437 # add env variable for cds-blueprints-processor container:
438 name: spring_profiles_active
441 - Spy CBA functionality with UAT initial seed file
445 curl -X POST -u ccsdkapps:ccsdkapps -F cba=@my_cba.zip -F uat=@input_uat.yaml http://<kube-node>:30499/api/v1/uat/spy
447 where my_cba.zip is the cba model of this use case and input_uat.yml is following in this use case:
454 - name: resource-assignment for vnf
456 commonHeader: &commonHeader
457 originatorId: SDNC_DG
458 requestId: "98397f54-fa57-485f-a04e-1e220b7b1779"
459 subRequestId: "6bfca5dc-993d-48f1-ad27-a7a9ea91836b"
460 actionIdentifiers: &actionIdentifiers
461 blueprintName: vFW_CNF_CDS
462 blueprintVersion: "1.0.45"
463 actionName: resource-assignment
466 resource-assignment-request:
469 resource-assignment-properties:
470 service-instance-id: &service-id "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
471 vnf-model-customization-uuid: &vnf-model-cust-uuid "86dc8af4-aa17-4fc7-9b20-f12160d99718"
472 vnf-id: &vnf-id "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
473 aic-cloud-region: &cloud-region "k8sregionfour"
474 - name: resource-assignment for base_template
476 commonHeader: *commonHeader
477 actionIdentifiers: *actionIdentifiers
479 resource-assignment-request:
482 resource-assignment-properties:
483 nfc-naming-code: "base_template"
484 k8s-rb-profile-name: &k8s-profile-name "default"
485 service-instance-id: *service-id
487 vf-module-model-customization-uuid: "b27fad11-44da-4840-9256-7ed8a32fbe3e"
488 vnf-model-customization-uuid: *vnf-model-cust-uuid
489 vf-module-id: "274f4bc9-7679-4767-b34d-1df51cdf2496"
490 aic-cloud-region: *cloud-region
491 - name: resource-assignment for vpkg
493 commonHeader: *commonHeader
494 actionIdentifiers: *actionIdentifiers
496 resource-assignment-request:
499 resource-assignment-properties:
500 nfc-naming-code: "vpkg"
501 k8s-rb-profile-name: *k8s-profile-name
502 service-instance-id: *service-id
504 vf-module-model-customization-uuid: "4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb"
505 vnf-model-customization-uuid: *vnf-model-cust-uuid
506 vf-module-id: "011b5f61-6524-4789-bd9a-44cfbf321463"
507 aic-cloud-region: *cloud-region
508 - name: resource-assignment for vsn
510 commonHeader: *commonHeader
511 actionIdentifiers: *actionIdentifiers
513 resource-assignment-request:
516 resource-assignment-properties:
517 nfc-naming-code: "vsn"
518 k8s-rb-profile-name: *k8s-profile-name
519 service-instance-id: *service-id
521 vf-module-model-customization-uuid: "4cac0584-c0d6-42a7-bdb3-29162792e07f"
522 vnf-model-customization-uuid: *vnf-model-cust-uuid
523 vf-module-id: "0cbf558f-5a96-4555-b476-7df8163521aa"
524 aic-cloud-region: *cloud-region
525 - name: resource-assignment for vfw
527 commonHeader: *commonHeader
528 actionIdentifiers: *actionIdentifiers
530 resource-assignment-request:
533 resource-assignment-properties:
534 nfc-naming-code: "vfw"
535 k8s-rb-profile-name: *k8s-profile-name
536 service-instance-id: *service-id
538 vf-module-model-customization-uuid: "1e123e43-ba40-4c93-90d7-b9f27407ec03"
539 vnf-model-customization-uuid: *vnf-model-cust-uuid
540 vf-module-id: "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f "
541 aic-cloud-region: *cloud-region
544 .. 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.
545 As an output of this call final uat.yml content is received. Final uat.yml in this use case looks like this:
550 - name: resource-assignment for vnf
553 originatorId: SDNC_DG
554 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
555 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
557 blueprintName: vFW_CNF_CDS
558 blueprintVersion: 1.0.45
559 actionName: resource-assignment
562 resource-assignment-request:
565 resource-assignment-properties:
566 service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72
567 vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718
568 vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0
569 aic-cloud-region: k8sregionfour
572 originatorId: SDNC_DG
573 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
574 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
577 blueprintName: vFW_CNF_CDS
578 blueprintVersion: 1.0.45
579 actionName: resource-assignment
583 eventType: EVENT_COMPONENT_EXECUTED
587 resource-assignment-response:
593 "capability-name": "generate-name",
596 "output-key-mapping": [
598 "resource-name": "vnf_name",
599 "resource-value": "${vnf_name}"
604 "param-name": "resource-name",
605 "param-value": "vnf_name"
608 "param-name": "resource-value",
609 "param-value": "${vnf_name}"
612 "param-name": "external-key",
613 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0_vnf_name"
616 "param-name": "policy-instance-name",
617 "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP"
620 "param-name": "naming-type",
624 "param-name": "AIC_CLOUD_REGION",
625 "param-value": "k8sregionfour"
632 "capability-name": "netbox-ip-assign",
635 "output-key-mapping": [
637 "resource-name": "int_private1_gw_ip",
638 "resource-value": "${int_private1_gw_ip}"
643 "param-name": "service-instance-id",
644 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
647 "param-name": "prefix-id",
651 "param-name": "vnf-id",
652 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
655 "param-name": "external_key",
656 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-int_private1_gw_ip"
661 "output-key-mapping": [
663 "resource-name": "int_private2_gw_ip",
664 "resource-value": "${int_private2_gw_ip}"
669 "param-name": "service-instance-id",
670 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
673 "param-name": "prefix-id",
677 "param-name": "vnf-id",
678 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
681 "param-name": "external_key",
682 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-int_private2_gw_ip"
687 "output-key-mapping": [
689 "resource-name": "vfw_int_private2_ip_0",
690 "resource-value": "${vfw_int_private2_ip_0}"
695 "param-name": "service-instance-id",
696 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
699 "param-name": "prefix-id",
703 "param-name": "vnf-id",
704 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
707 "param-name": "external_key",
708 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vfw_int_private2_ip_0"
713 "output-key-mapping": [
715 "resource-name": "vfw_int_private1_ip_0",
716 "resource-value": "${vfw_int_private1_ip_0}"
721 "param-name": "service-instance-id",
722 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
725 "param-name": "prefix-id",
729 "param-name": "vnf-id",
730 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
733 "param-name": "external_key",
734 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vfw_int_private1_ip_0"
739 "output-key-mapping": [
741 "resource-name": "vsn_int_private2_ip_0",
742 "resource-value": "${vsn_int_private2_ip_0}"
747 "param-name": "service-instance-id",
748 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
751 "param-name": "prefix-id",
755 "param-name": "vnf-id",
756 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
759 "param-name": "external_key",
760 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vsn_int_private2_ip_0"
765 "output-key-mapping": [
767 "resource-name": "vpg_int_private1_ip_0",
768 "resource-value": "${vpg_int_private1_ip_0}"
773 "param-name": "service-instance-id",
774 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
777 "param-name": "prefix-id",
781 "param-name": "vnf-id",
782 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
785 "param-name": "external_key",
786 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vpg_int_private1_ip_0"
793 "capability-name": "unresolved-composite-data",
796 "output-key-mapping": [
798 "resource-name": "int_private2_net_id",
799 "resource-value": "${vnf_name}-protected-network"
802 "resource-name": "int_private1_net_id",
803 "resource-value": "${vnf_name}-unprotected-network"
806 "resource-name": "onap_private_net_id",
807 "resource-value": "${vnf_name}-management-network"
810 "resource-name": "net_attachment_definition",
811 "resource-value": "${vnf_name}-ovn-nat"
818 "resource-accumulator-resolved-data": [
820 "param-name": "vf-naming-policy",
821 "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP"
824 "param-name": "dcae_collector_ip",
825 "param-value": "10.0.4.1"
828 "param-name": "dcae_collector_port",
829 "param-value": "30235"
832 "param-name": "int_private1_net_cidr",
833 "param-value": "192.168.10.0/24"
836 "param-name": "int_private2_net_cidr",
837 "param-value": "192.168.20.0/24"
840 "param-name": "onap_private_net_cidr",
841 "param-value": "10.0.101.0/24"
844 "param-name": "demo_artifacts_version",
845 "param-value": "1.5.0"
848 "param-name": "k8s-rb-profile-name",
849 "param-value": "vfw-cnf-cds-base-profile"
852 "param-name": "k8s-rb-profile-namespace",
853 "param-value": "default"
857 - name: resource-assignment for base_template
860 originatorId: SDNC_DG
861 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
862 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
864 blueprintName: vFW_CNF_CDS
865 blueprintVersion: 1.0.45
866 actionName: resource-assignment
869 resource-assignment-request:
872 resource-assignment-properties:
873 nfc-naming-code: base_template
874 k8s-rb-profile-name: default
875 service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72
876 vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0
877 vf-module-model-customization-uuid: b27fad11-44da-4840-9256-7ed8a32fbe3e
878 vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718
879 vf-module-id: 274f4bc9-7679-4767-b34d-1df51cdf2496
880 aic-cloud-region: k8sregionfour
883 originatorId: SDNC_DG
884 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
885 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
888 blueprintName: vFW_CNF_CDS
889 blueprintVersion: 1.0.45
890 actionName: resource-assignment
894 eventType: EVENT_COMPONENT_EXECUTED
898 resource-assignment-response:
904 "capability-name": "netbox-ip-assign",
907 "output-key-mapping": [
909 "resource-name": "onap_private_gw_ip",
910 "resource-value": "${onap_private_gw_ip}"
915 "param-name": "service-instance-id",
916 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
919 "param-name": "prefix-id",
923 "param-name": "vnf-id",
924 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
927 "param-name": "external_key",
928 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-onap_private_gw_ip"
935 "capability-name": "generate-name",
938 "output-key-mapping": [
940 "resource-name": "vf_module_name",
941 "resource-value": "${vf-module-name}"
946 "param-name": "resource-name",
947 "param-value": "vf_module_name"
950 "param-name": "resource-value",
951 "param-value": "${vf-module-name}"
954 "param-name": "external-key",
955 "param-value": "274f4bc9-7679-4767-b34d-1df51cdf2496_vf-module-name"
958 "param-name": "policy-instance-name",
959 "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP"
962 "param-name": "naming-type",
963 "param-value": "VF-MODULE"
966 "param-name": "VNF_NAME",
967 "param-value": "k8sregionfour-onap-nf-20200601t073308018z"
970 "param-name": "VF_MODULE_TYPE",
971 "param-value": "vfmt"
974 "param-name": "VF_MODULE_LABEL",
975 "param-value": "base_template"
982 "capability-name": "aai-vf-module-put",
985 "output-key-mapping": [
987 "resource-name": "aai-vf-module-put",
995 "resource-accumulator-resolved-data": [
997 "param-name": "vf-module-model-invariant-uuid",
998 "param-value": "52842255-b7be-4a1c-ab3b-2bd3bd4a5423"
1001 "param-name": "vf-module-model-version",
1002 "param-value": "274f4bc9-7679-4767-b34d-1df51cdf2496"
1005 "param-name": "k8s-rb-profile-name",
1006 "param-value": "default"
1009 "param-name": "k8s-rb-profile-namespace",
1010 "param-value": "default"
1013 "param-name": "int_private1_subnet_id",
1014 "param-value": "unprotected-network-subnet-1"
1017 "param-name": "int_private2_subnet_id",
1018 "param-value": "protected-network-subnet-1"
1021 "param-name": "onap_private_subnet_id",
1022 "param-value": "management-network-subnet-1"
1026 - name: resource-assignment for vpkg
1029 originatorId: SDNC_DG
1030 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
1031 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
1033 blueprintName: vFW_CNF_CDS
1034 blueprintVersion: 1.0.45
1035 actionName: resource-assignment
1038 resource-assignment-request:
1041 resource-assignment-properties:
1042 nfc-naming-code: vpkg
1043 k8s-rb-profile-name: default
1044 service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72
1045 vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0
1046 vf-module-model-customization-uuid: 4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb
1047 vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718
1048 vf-module-id: 011b5f61-6524-4789-bd9a-44cfbf321463
1049 aic-cloud-region: k8sregionfour
1052 originatorId: SDNC_DG
1053 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
1054 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
1057 blueprintName: vFW_CNF_CDS
1058 blueprintVersion: 1.0.45
1059 actionName: resource-assignment
1063 eventType: EVENT_COMPONENT_EXECUTED
1067 resource-assignment-response:
1071 "capability-data": [
1073 "capability-name": "netbox-ip-assign",
1076 "output-key-mapping": [
1078 "resource-name": "vpg_onap_private_ip_0",
1079 "resource-value": "${vpg_onap_private_ip_0}"
1084 "param-name": "service-instance-id",
1085 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
1088 "param-name": "prefix-id",
1092 "param-name": "vnf-id",
1093 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0"
1096 "param-name": "external_key",
1097 "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vpg_onap_private_ip_0"
1104 "capability-name": "generate-name",
1107 "output-key-mapping": [
1109 "resource-name": "vf_module_name",
1110 "resource-value": "${vf-module-name}"
1115 "param-name": "VF_MODULE_TYPE",
1116 "param-value": "vfmt"
1119 "param-name": "resource-name",
1120 "param-value": "vf_module_name"
1123 "param-name": "resource-value",
1124 "param-value": "${vf-module-name}"
1127 "param-name": "external-key",
1128 "param-value": "011b5f61-6524-4789-bd9a-44cfbf321463_vf-module-name"
1131 "param-name": "policy-instance-name",
1132 "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP"
1135 "param-name": "naming-type",
1136 "param-value": "VF-MODULE"
1139 "param-name": "VNF_NAME",
1140 "param-value": "k8sregionfour-onap-nf-20200601t073308018z"
1143 "param-name": "VF_MODULE_LABEL",
1144 "param-value": "vpkg"
1151 "capability-name": "aai-vf-module-put",
1154 "output-key-mapping": [
1156 "resource-name": "aai-vf-module-put",
1157 "resource-value": ""
1164 "capability-name": "unresolved-composite-data",
1167 "output-key-mapping": [
1169 "resource-name": "vpg_name_0",
1170 "resource-value": "${vf_module_name}"
1177 "resource-accumulator-resolved-data": [
1179 "param-name": "vf-module-model-invariant-uuid",
1180 "param-value": "4e2b9975-5214-48b8-861a-5701c09eedfa"
1183 "param-name": "vf-module-model-version",
1184 "param-value": "011b5f61-6524-4789-bd9a-44cfbf321463"
1187 "param-name": "k8s-rb-profile-name",
1188 "param-value": "default"
1191 "param-name": "k8s-rb-profile-namespace",
1192 "param-value": "default"
1196 - name: resource-assignment for vsn
1199 originatorId: SDNC_DG
1200 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
1201 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
1203 blueprintName: vFW_CNF_CDS
1204 blueprintVersion: 1.0.45
1205 actionName: resource-assignment
1208 resource-assignment-request:
1211 resource-assignment-properties:
1212 nfc-naming-code: vsn
1213 k8s-rb-profile-name: default
1214 service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72
1215 vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0
1216 vf-module-model-customization-uuid: 4cac0584-c0d6-42a7-bdb3-29162792e07f
1217 vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718
1218 vf-module-id: 0cbf558f-5a96-4555-b476-7df8163521aa
1219 aic-cloud-region: k8sregionfour
1222 originatorId: SDNC_DG
1223 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
1224 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
1227 blueprintName: vFW_CNF_CDS
1228 blueprintVersion: 1.0.45
1229 actionName: resource-assignment
1233 eventType: EVENT_COMPONENT_EXECUTED
1237 resource-assignment-response:
1241 "capability-data": [
1243 "capability-name": "generate-name",
1246 "output-key-mapping": [
1248 "resource-name": "vf_module_name",
1249 "resource-value": "${vf-module-name}"
1254 "param-name": "VF_MODULE_TYPE",
1255 "param-value": "vfmt"
1258 "param-name": "resource-name",
1259 "param-value": "vf_module_name"
1262 "param-name": "resource-value",
1263 "param-value": "${vf-module-name}"
1266 "param-name": "external-key",
1267 "param-value": "0cbf558f-5a96-4555-b476-7df8163521aa_vf-module-name"
1270 "param-name": "policy-instance-name",
1271 "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP"
1274 "param-name": "naming-type",
1275 "param-value": "VF-MODULE"
1278 "param-name": "VNF_NAME",
1279 "param-value": "k8sregionfour-onap-nf-20200601t073308018z"
1282 "param-name": "VF_MODULE_LABEL",
1283 "param-value": "vsn"
1290 "capability-name": "netbox-ip-assign",
1293 "output-key-mapping": [
1295 "resource-name": "vsn_onap_private_ip_0",
1296 "resource-value": "${vsn_onap_private_ip_0}"
1301 "param-name": "service-instance-id",
1302 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
1305 "param-name": "prefix-id",
1309 "param-name": "vf_module_id",
1310 "param-value": "0cbf558f-5a96-4555-b476-7df8163521aa"
1313 "param-name": "external_key",
1314 "param-value": "0cbf558f-5a96-4555-b476-7df8163521aa-vsn_onap_private_ip_0"
1321 "capability-name": "aai-vf-module-put",
1324 "output-key-mapping": [
1326 "resource-name": "aai-vf-module-put",
1327 "resource-value": ""
1334 "capability-name": "unresolved-composite-data",
1337 "output-key-mapping": [
1339 "resource-name": "vsn_name_0",
1340 "resource-value": "${vf_module_name}"
1347 "resource-accumulator-resolved-data": [
1349 "param-name": "vf-module-model-invariant-uuid",
1350 "param-value": "36f25e1b-199b-4de2-b656-c870d341cf0e"
1353 "param-name": "vf-module-model-version",
1354 "param-value": "0cbf558f-5a96-4555-b476-7df8163521aa"
1357 "param-name": "k8s-rb-profile-name",
1358 "param-value": "default"
1361 "param-name": "k8s-rb-profile-namespace",
1362 "param-value": "default"
1366 - name: resource-assignment for vfw
1369 originatorId: SDNC_DG
1370 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
1371 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
1373 blueprintName: vFW_CNF_CDS
1374 blueprintVersion: 1.0.45
1375 actionName: resource-assignment
1378 resource-assignment-request:
1381 resource-assignment-properties:
1382 nfc-naming-code: vfw
1383 k8s-rb-profile-name: default
1384 service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72
1385 vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0
1386 vf-module-model-customization-uuid: 1e123e43-ba40-4c93-90d7-b9f27407ec03
1387 vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718
1388 vf-module-id: '0de4ed56-8b4c-4a2d-8ce6-85d5e269204f '
1389 aic-cloud-region: k8sregionfour
1392 originatorId: SDNC_DG
1393 requestId: 98397f54-fa57-485f-a04e-1e220b7b1779
1394 subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b
1397 blueprintName: vFW_CNF_CDS
1398 blueprintVersion: 1.0.45
1399 actionName: resource-assignment
1403 eventType: EVENT_COMPONENT_EXECUTED
1407 resource-assignment-response:
1411 "capability-data": [
1413 "capability-name": "generate-name",
1416 "output-key-mapping": [
1418 "resource-name": "vf_module_name",
1419 "resource-value": "${vf-module-name}"
1424 "param-name": "VF_MODULE_TYPE",
1425 "param-value": "vfmt"
1428 "param-name": "resource-name",
1429 "param-value": "vf_module_name"
1432 "param-name": "resource-value",
1433 "param-value": "${vf-module-name}"
1436 "param-name": "external-key",
1437 "param-value": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f _vf-module-name"
1440 "param-name": "policy-instance-name",
1441 "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP"
1444 "param-name": "naming-type",
1445 "param-value": "VF-MODULE"
1448 "param-name": "VNF_NAME",
1449 "param-value": "k8sregionfour-onap-nf-20200601t073308018z"
1452 "param-name": "VF_MODULE_LABEL",
1453 "param-value": "vfw"
1460 "capability-name": "netbox-ip-assign",
1463 "output-key-mapping": [
1465 "resource-name": "vfw_onap_private_ip_0",
1466 "resource-value": "${vfw_onap_private_ip_0}"
1471 "param-name": "service-instance-id",
1472 "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72"
1475 "param-name": "prefix-id",
1479 "param-name": "vf_module_id",
1480 "param-value": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f "
1483 "param-name": "external_key",
1484 "param-value": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f -vfw_onap_private_ip_0"
1491 "capability-name": "aai-vf-module-put",
1494 "output-key-mapping": [
1496 "resource-name": "aai-vf-module-put",
1497 "resource-value": ""
1504 "capability-name": "unresolved-composite-data",
1507 "output-key-mapping": [
1509 "resource-name": "vfw_name_0",
1510 "resource-value": "${vf_module_name}"
1517 "resource-accumulator-resolved-data": [
1519 "param-name": "vf-module-model-invariant-uuid",
1520 "param-value": "9ffda670-3d77-4f6c-a4ad-fb7a09f19817"
1523 "param-name": "vf-module-model-version",
1524 "param-value": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f"
1527 "param-name": "k8s-rb-profile-name",
1528 "param-value": "default"
1531 "param-name": "k8s-rb-profile-namespace",
1532 "param-value": "default"
1541 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
1546 - name: vf-naming-policy
1547 value: SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP
1548 resource-resolution-data:
1549 capability-name: RA Resolved
1552 Content-Type: application/json
1556 - Verify CBA with UAT
1560 curl -X POST -u ccsdkapps:ccsdkapps -F cba=@my_cba.zip http://<kube-node>:30499/api/v1/uat/verify
1562 where my_cba.zip is the CBA model with uat.yml (generated in spy step) inside Test folder.
1564 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.
1566 Instantiation Overview
1567 ----------------------
1569 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.
1571 .. figure:: files/vFW_CNF_CDS/Instantiation_topology.png
1574 vFW CNF CDS Use Case Runtime interactions.
1576 PART 1 - ONAP Installation
1577 ~~~~~~~~~~~~~~~~~~~~~~~~~~
1579 1-1 Deployment components
1580 .........................
1582 In order to run the vFW_CNF_CDS use case, we need ONAP Frankfurt Release (or later) and at least following components:
1584 ======================================================= ===========
1585 ONAP Component name Describtion
1586 ------------------------------------------------------- -----------
1587 AAI Required for Inventory Cloud Owner, Customer, Owning Entity, Service, Generic VNF, VF Module
1588 SDC VSP, VF and Service Modeling of the CNF
1589 DMAAP Distribution of the onboarding package including CBA to all ONAP components
1590 SO Requires for Macro Orchestration using the generic building blocks
1591 CDS Resolution of cloud parameters including Helm override parameters for the CNF. Creation of the multicloud/k8s profile for CNF instantion.
1592 SDNC (needs to include netbox and Naming Generation mS) Provides GENERIC-RESOURCE-API for cloud Instantiation orchestration via CDS.
1593 Policy Used to Store Naming Policy
1594 AAF Used for Authentication and Authorization of requests
1595 Portal Required to access SDC.
1596 MSB Exposes multicloud interfaces used by SO.
1597 Multicloud K8S plugin part used to pass SO instantiation requests to external Kubernetes cloud region.
1598 Contrib Chart containing multiple external components. Out of those, we only use Netbox utility in this use-case for IPAM
1599 Robot Optional. Can be used for running automated tasks, like provisioning cloud customer, cloud region, service subscription, etc ..
1600 Shared Cassandra DB Used as a shared storage for ONAP components that rely on Cassandra DB, like AAI
1601 Shared Maria DB Used as a shared storage for ONAP components that rely on Maria DB, like SDNC, and SO
1602 ======================================================= ===========
1607 In order to deploy such an instance, follow the `ONAP Deployment Guide`_
1609 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.
1611 **override.yaml** file where enabled: true is set for each component needed in demo (by default all components are disabled).
1646 Then deploy ONAP with Helm with your override file.
1650 helm deploy onap local/onap --namespace onap -f ~/override.yaml
1652 In case redeployment needed `Helm Healer`_ could be a faster and convenient way to redeploy.
1656 helm-healer.sh -n onap -f ~/override.yaml -s /dockerdata-nfs --delete-all
1658 Or redeploy (clean re-deploy also data removed) just wanted components (Helm releases), cds in this example.
1662 helm-healer.sh -f ~/override.yaml -s /dockerdata-nfs/ -n onap -c onap-cds
1664 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*.
1670 for comp in {aaf,aai,dmaap,msb,multicloud,policy,portal,sdc,sdnc,so}; do
1671 if ! ./ete-k8s.sh onap health-$comp; then
1672 failed=$failed,$comp
1675 if [ -n "$failed" ]; then
1676 echo "These components failed: $failed"
1679 echo "Healthcheck successful"
1683 And check status of pods, deployments, jobs etc.
1687 kubectl -n onap get pods | grep -vie 'completed' -e 'running'
1688 kubectl -n onap get deploy,sts,jobs
1694 After completing the first part above, we should have a functional ONAP deployment for the Frankfurt Release.
1696 We will need to apply a few modifications to the deployed ONAP Frankfurt instance in order to run the use case.
1698 Retrieving logins and passwords of ONAP components
1699 ++++++++++++++++++++++++++++++++++++++++++++++++++
1701 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.
1705 kubectl get secret `kubectl get secrets | grep mariadb-galera-db-root-password | awk '{print $1}'` -o jsonpath="{.data.login}" | base64 --decode
1706 kubectl get secret `kubectl get secrets | grep mariadb-galera-db-root-password | awk '{print $1}'` -o jsonpath="{.data.password}" | base64 --decode
1708 In this case login is empty as the secret is dedicated to root user.
1710 Postman collection setup
1711 ++++++++++++++++++++++++
1713 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.
1715 Postman collection is used also to trigger instantiation using SO APIs.
1717 Following steps are needed to setup Postman:
1719 - Import this Postman collection zip
1721 :download:`Postman collection <files/vFW_CNF_CDS/postman.zip>`
1723 - 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.
1724 - `vFW_CNF_CDS.postman_collection.json`
1725 - `vFW_CNF_CDS.postman_environment.json`
1727 - 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.
1731 kubectl -n onap edit svc so-catalog-db-adapter
1732 - .spec.type: ClusterIP
1733 + .spec.type: NodePort
1734 + .spec.ports[0].nodePort: 30120
1736 .. note:: The port number 30120 is used in included Postman collection
1738 - 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:
1742 kubectl edit -n onap svc cds-blueprints-processor-http
1743 - .spec.type: ClusterIP
1744 + .spec.type: NodePort
1745 + .spec.ports[0].nodePort: 30499
1747 .. note:: The port number 30499 is used in included Postman collection
1749 **Postman variables:**
1751 Most of the Postman variables are automated by Postman scripts and environment file provided, but there are few mandatory variables to fill by user.
1753 ===================== ===================
1754 Variable Description
1755 --------------------- -------------------
1756 k8s ONAP Kubernetes host
1757 sdnc_port port of sdnc service for accessing MDSAL
1758 service-name name of service as defined in SDC
1759 service-version version of service defined in SDC (if service wasn't updated, it should be set to "1.0")
1760 service-instance-name name of instantiated service (if ending with -{num}, will be autoincremented for each instantiation request)
1761 ===================== ===================
1763 You can get the sdnc_port value with
1767 kubectl -n onap get svc sdnc -o json | jq '.spec.ports[]|select(.port==8282).nodePort'
1773 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.
1775 Create all these entries into AAI in this order. Postman collection provided in this demo can be used for creating each entry.
1777 **Postman -> Initial ONAP setup -> Create**
1780 - Create Owning-entity
1783 - Create Line Of Business
1785 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.
1787 SO BPMN endpoint fix for VNF adapter requests (v1 -> v2)
1788 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1790 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.
1794 kubectl -n onap edit configmap onap-so-bpmn-infra-app-configmap
1795 - .data."override.yaml".mso.adapters.vnf.rest.endpoint: http://so-openstack-adapter.onap:8087/services/rest/v1/vnfs
1796 + .data."override.yaml".mso.adapters.vnf.rest.endpoint: http://so-openstack-adapter.onap:8087/services/rest/v2/vnfs
1797 kubectl -n onap delete pod -l app=so-bpmn-infra
1802 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.
1804 This usecase leverages default ONAP naming policy - "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP".
1805 To check that the naming policy is created and pushed OK, we can run the command below from inside any ONAP pod.
1809 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"
1811 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
1813 **Network Naming mS**
1815 FIXME - Verify if on RC2 this still needs to be performed
1817 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.
1819 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
1823 # Go into naming service database
1824 kubectl -n onap exec onap-mariadb-galera-0 -it -- mysql -uroot -psecretpassword -D nengdb
1825 select * from EXTERNAL_INTERFACE;
1826 # Delete entries from EXTERNAL_INTERFACE table
1827 delete from EXTERNAL_INTERFACE;
1828 select * from EXTERNAL_INTERFACE;
1830 PART 2 - Installation of managed Kubernetes cluster
1831 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1833 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.
1835 2-1 Installation of Managed Kubernetes
1836 ......................................
1838 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`_.
1840 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.
1842 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:
1848 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.
1850 2-2 Cloud Registration
1851 ......................
1853 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.
1855 Postman collection have folder/entry for each step. Execute in this order.
1857 **Postman -> K8s Cloud Region Registration -> Create**
1860 - Create Cloud Region
1861 - Create Complex-Cloud Region Relationship
1863 - Create Service Subscription
1864 - Create Cloud Tenant
1865 - Create Availability Zone
1866 - Upload Connectivity Info
1868 .. 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.
1870 **SO Cloud region configuration**
1872 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.
1874 The related code part in SO is here: `SO Cloud Region Selection`_
1875 It's possible improvement place in SO to rather get this information directly from AAI.
1877 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
1881 kubectl -n onap exec onap-mariadb-galera-0 -it -- mysql -uroot -psecretpassword -D catalogdb
1882 select * from cloud_sites;
1883 insert into cloud_sites(ID, REGION_ID, IDENTITY_SERVICE_ID, CLOUD_VERSION, CLLI, ORCHESTRATOR) values("k8sregionfour", "k8sregionfour", "DEFAULT_KEYSTONE", "2.5", "clli2", "multicloud");
1884 select * from cloud_sites;
1887 PART 3 - Execution of the Use Case
1888 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1890 This part contains all the steps to run the use case by using ONAP GUIs and Postman.
1892 Following picture describes the overall sequential flow of the use case.
1894 .. figure:: files/vFW_CNF_CDS/vFW_CNF_CDS_Flow.png
1897 vFW CNF CDS Use Case sequence flow.
1902 Creating Onboarding Package
1903 +++++++++++++++++++++++++++
1905 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.
1907 Complete content can be packaged to single onboarding package file in the following way:
1909 .. note:: Requires Helm installed
1913 git clone https://gerrit.onap.org/r/demo
1914 cd heat/vFW_CNF_CDS/templates
1917 The output looks like:
1922 make[1]: Entering directory '/home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm'
1923 rm -f base_template-*.tgz
1924 rm -f base_template_cloudtech_k8s_charts.tgz
1925 helm package base_template
1926 Successfully packaged chart and saved it to: /home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm/base_template-0.2.0.tgz
1927 mv base_template-*.tgz base_template_cloudtech_k8s_charts.tgz
1929 rm -f vpkg_cloudtech_k8s_charts.tgz
1931 Successfully packaged chart and saved it to: /home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm/vpkg-0.2.0.tgz
1932 mv vpkg-*.tgz vpkg_cloudtech_k8s_charts.tgz
1934 rm -f vfw_cloudtech_k8s_charts.tgz
1936 Successfully packaged chart and saved it to: /home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm/vfw-0.2.0.tgz
1937 mv vfw-*.tgz vfw_cloudtech_k8s_charts.tgz
1939 rm -f vsn_cloudtech_k8s_charts.tgz
1941 Successfully packaged chart and saved it to: /home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm/vsn-0.2.0.tgz
1942 mv vsn-*.tgz vsn_cloudtech_k8s_charts.tgz
1943 make[1]: Leaving directory '/home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm'
1944 mv helm/*.tgz package/
1946 cd cba/ && zip -r vFW_CDS_CNF.zip .
1947 adding: TOSCA-Metadata/ (stored 0%)
1948 adding: TOSCA-Metadata/TOSCA.meta (deflated 38%)
1949 adding: Templates/ (stored 0%)
1950 adding: Templates/base_template-mapping.json (deflated 92%)
1951 adding: Templates/vfw-template.vtl (deflated 87%)
1952 adding: Templates/nf-params-mapping.json (deflated 86%)
1953 adding: Templates/vsn-mapping.json (deflated 94%)
1954 adding: Templates/vnf-template.vtl (deflated 90%)
1955 adding: Templates/vpkg-mapping.json (deflated 94%)
1956 adding: Templates/vsn-template.vtl (deflated 87%)
1957 adding: Templates/nf-params-template.vtl (deflated 44%)
1958 adding: Templates/base_template-template.vtl (deflated 85%)
1959 adding: Templates/vfw-mapping.json (deflated 94%)
1960 adding: Templates/vnf-mapping.json (deflated 92%)
1961 adding: Templates/vpkg-template.vtl (deflated 86%)
1962 adding: Templates/k8s-profiles/ (stored 0%)
1963 adding: Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz (stored 0%)
1964 adding: Scripts/ (stored 0%)
1965 adding: Scripts/kotlin/ (stored 0%)
1966 adding: Scripts/kotlin/KotlinK8sProfileUpload.kt (deflated 75%)
1967 adding: Scripts/kotlin/README.md (stored 0%)
1968 adding: Definitions/ (stored 0%)
1969 adding: Definitions/artifact_types.json (deflated 57%)
1970 adding: Definitions/vFW_CNF_CDS.json (deflated 81%)
1971 adding: Definitions/node_types.json (deflated 86%)
1972 adding: Definitions/policy_types.json (stored 0%)
1973 adding: Definitions/data_types.json (deflated 93%)
1974 adding: Definitions/resources_definition_types.json (deflated 95%)
1975 adding: Definitions/relationship_types.json (stored 0%)
1976 mv cba/vFW_CDS_CNF.zip package/
1977 #Can't use .package extension or SDC will panic
1978 cd package/ && zip -r vfw_k8s_demo.zip .
1979 adding: base_template_cloudtech_k8s_charts.tgz (stored 0%)
1980 adding: MANIFEST.json (deflated 83%)
1981 adding: base_template.yaml (deflated 63%)
1982 adding: vsn_cloudtech_k8s_charts.tgz (stored 0%)
1983 adding: vfw_cloudtech_k8s_charts.tgz (stored 0%)
1984 adding: vpkg_cloudtech_k8s_charts.tgz (stored 0%)
1985 adding: vsn.yaml (deflated 75%)
1986 adding: vpkg.yaml (deflated 76%)
1987 adding: vfw.yaml (deflated 77%)
1988 adding: vFW_CDS_CNF.zip (stored 0%)
1989 adding: base_template.env (deflated 23%)
1990 adding: vsn.env (deflated 53%)
1991 adding: vpkg.env (deflated 55%)
1992 adding: vfw.env (deflated 58%)
1993 mv package/vfw_k8s_demo.zip .
1996 and package **vfw_k8s_demo.zip** file is created containing all sub-models.
1998 Import this package into SDC and follow onboarding steps.
2000 Service Creation with SDC
2001 +++++++++++++++++++++++++
2003 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`_
2007 - Remember during VSP onboard to choose "Network Package" Onboarding procedure
2009 Create VF and Service
2010 Service -> Properties Assignment -> Choose VF (at right box):
2012 - skip_post_instantiation_configuration - True
2013 - sdnc_artifact_name - vnf
2014 - sdnc_model_name - vFW_CNF_CDS
2015 - sdnc_model_version - 1.0.45
2017 Distribution Of Service
2018 +++++++++++++++++++++++
2022 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:
2026 SDC Catalog database should have our service now defined.
2028 **Postman -> LCM -> [SDC] Catalog Service**
2033 "uuid": "64dd38f3-2307-4e0a-bc98-5c2cbfb260b6",
2034 "invariantUUID": "cd1a5c2d-2d4e-4d62-ac10-a5fe05e32a22",
2035 "name": "vfw_cnf_cds_svc",
2037 "toscaModelURL": "/sdc/v1/catalog/services/64dd38f3-2307-4e0a-bc98-5c2cbfb260b6/toscaModel",
2038 "category": "Network L4+",
2039 "lifecycleState": "CERTIFIED",
2040 "lastUpdaterUserId": "cs0008",
2041 "distributionStatus": "DISTRIBUTED"
2045 Listing should contain entry with our service name **vfw_cnf_cds_svc**.
2047 .. 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.
2051 SO Catalog database should have our service NFs defined now.
2053 **Postman -> LCM -> [SO] Catalog DB Service xNFs**
2061 "modelName": "vfw_cnf_cds_vsp",
2062 "modelUuid": "70edaca8-8c79-468a-aa76-8224cfe686d0",
2063 "modelInvariantUuid": "7901fc89-a94d-434a-8454-1e27b99dc0e2",
2064 "modelVersion": "1.0",
2065 "modelCustomizationUuid": "86dc8af4-aa17-4fc7-9b20-f12160d99718",
2066 "modelInstanceName": "vfw_cnf_cds_vsp 0"
2068 "toscaNodeType": "org.openecomp.resource.vf.VfwCnfCdsVsp",
2072 "nfNamingCode": null,
2073 "multiStageDesign": "false",
2074 "vnfcInstGroupOrder": null,
2075 "resourceInput": "TBD",
2079 "modelName": "VfwCnfCdsVsp..base_template..module-0",
2080 "modelUuid": "274f4bc9-7679-4767-b34d-1df51cdf2496",
2081 "modelInvariantUuid": "52842255-b7be-4a1c-ab3b-2bd3bd4a5423",
2082 "modelVersion": "1",
2083 "modelCustomizationUuid": "b27fad11-44da-4840-9256-7ed8a32fbe3e"
2086 "vfModuleLabel": "base_template",
2088 "hasVolumeGroup": false
2092 "modelName": "VfwCnfCdsVsp..vsn..module-1",
2093 "modelUuid": "0cbf558f-5a96-4555-b476-7df8163521aa",
2094 "modelInvariantUuid": "36f25e1b-199b-4de2-b656-c870d341cf0e",
2095 "modelVersion": "1",
2096 "modelCustomizationUuid": "4cac0584-c0d6-42a7-bdb3-29162792e07f"
2099 "vfModuleLabel": "vsn",
2101 "hasVolumeGroup": false
2105 "modelName": "VfwCnfCdsVsp..vpkg..module-2",
2106 "modelUuid": "011b5f61-6524-4789-bd9a-44cfbf321463",
2107 "modelInvariantUuid": "4e2b9975-5214-48b8-861a-5701c09eedfa",
2108 "modelVersion": "1",
2109 "modelCustomizationUuid": "4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb"
2112 "vfModuleLabel": "vpkg",
2114 "hasVolumeGroup": false
2118 "modelName": "VfwCnfCdsVsp..vfw..module-3",
2119 "modelUuid": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f",
2120 "modelInvariantUuid": "9ffda670-3d77-4f6c-a4ad-fb7a09f19817",
2121 "modelVersion": "1",
2122 "modelCustomizationUuid": "1e123e43-ba40-4c93-90d7-b9f27407ec03"
2125 "vfModuleLabel": "vfw",
2127 "hasVolumeGroup": false
2137 SDNC should have it's database updated with sdnc_* properties that were set during service modeling.
2139 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
2143 kubectl -n onap exec onap-mariadb-galera-0 -it -- sh
2144 mysql -uroot -psecretpassword -D sdnctl
2145 MariaDB [sdnctl]> select sdnc_model_name, sdnc_model_version, sdnc_artifact_name from VF_MODEL WHERE customization_uuid = '86dc8af4-aa17-4fc7-9b20-f12160d99718';
2146 +-----------------+--------------------+--------------------+
2147 | sdnc_model_name | sdnc_model_version | sdnc_artifact_name |
2148 +-----------------+--------------------+--------------------+
2149 | vFW_CNF_CDS | 1.0.45 | vnf |
2150 +-----------------+--------------------+--------------------+
2151 1 row in set (0.00 sec)
2154 .. note:: customization_uuid value is the modelCustomizationUuid of the VNF (serviceVnfs response in 2nd Postman call from SO Catalog DB)
2158 CDS should onboard CBA uploaded as part of VF.
2160 **Postman -> Distribution Verification -> [CDS] List CBAs**
2167 "id": "c505e516-b35d-4181-b1e2-bcba361cfd0a",
2168 "artifactUUId": null,
2169 "artifactType": "SDNC_MODEL",
2170 "artifactVersion": "1.0.45",
2171 "artifactDescription": "Controller Blueprint for vFW_CNF_CDS:1.0.45",
2172 "internalVersion": null,
2173 "createdDate": "2020-05-29T06:02:20.000Z",
2174 "artifactName": "vFW_CNF_CDS",
2176 "updatedBy": "Samuli Silvius <s.silvius@partner.samsung.com>",
2177 "tags": "Samuli Silvius, vFW_CNF_CDS"
2182 The list should have the matching entries with SDNC database:
2184 - sdnc_model_name == artifactName
2185 - sdnc_model_version == artifactVersion
2187 You can also use **Postman -> Distribution Verification -> [CDS] CBA Download** to download CBA for further verification but it's fully optional.
2191 K8splugin should onboard 4 resource bundles related to helm resources:
2193 **Postman -> Distribution Verification -> [K8splugin] List Resource Bundle Definitions**
2199 "rb-name": "52842255-b7be-4a1c-ab3b-2bd3bd4a5423",
2200 "rb-version": "274f4bc9-7679-4767-b34d-1df51cdf2496",
2201 "chart-name": "base_template",
2204 "vnf_customization_uuid": "b27fad11-44da-4840-9256-7ed8a32fbe3e"
2208 "rb-name": "36f25e1b-199b-4de2-b656-c870d341cf0e",
2209 "rb-version": "0cbf558f-5a96-4555-b476-7df8163521aa",
2210 "chart-name": "vsn",
2213 "vnf_customization_uuid": "4cac0584-c0d6-42a7-bdb3-29162792e07f"
2217 "rb-name": "4e2b9975-5214-48b8-861a-5701c09eedfa",
2218 "rb-version": "011b5f61-6524-4789-bd9a-44cfbf321463",
2219 "chart-name": "vpkg",
2222 "vnf_customization_uuid": "4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb"
2226 "rb-name": "9ffda670-3d77-4f6c-a4ad-fb7a09f19817",
2227 "rb-version": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f",
2228 "chart-name": "vfw",
2231 "vnf_customization_uuid": "1e123e43-ba40-4c93-90d7-b9f27407ec03"
2236 3-2 CNF Instantiation
2237 .....................
2239 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.
2241 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:
2243 - **Postman -> LCM -> 1.[SDC] Catalog Service**
2244 - **Postman -> LCM -> 2. [SO] Catalog DB Service xNFs**
2246 Now actual instantiation can be triggered with:
2248 **Postman -> LCM -> 3. [SO] Self-Serve Service Assign & Activate**
2250 Follow progress with SO's GET request:
2252 **Postman -> LCM -> 4. [SO] Infra Active Requests**
2254 The successful reply payload in that query should start like this:
2259 "requestStatus": "COMPLETE",
2260 "statusMessage": "Macro-Service-createInstance request was executed correctly.",
2261 "flowStatus": "Successfully completed all Building Blocks",
2263 "startTime": 1590996766000,
2264 "endTime": 1590996945000,
2265 "source": "Postman",
2266 "vnfId": "93b3350d-ed6f-413b-9cc5-a158c1676eb0",
2268 "requestBody": "**REDACTED FOR READABILITY**",
2269 "lastModifiedBy": "CamundaBPMN",
2270 "modifyTime": "2020-06-01T07:35:45.000+0000",
2271 "cloudRegion": "k8sregionfour",
2272 "serviceInstanceId": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72",
2273 "serviceInstanceName": "vfw-cnf-16",
2274 "requestScope": "service",
2275 "requestAction": "createInstance",
2276 "requestorId": "11c2ddb7-4659-4bf0-a685-a08dcbb5a099",
2277 "requestUrl": "http://infra:30277/onap/so/infra/serviceInstantiation/v7/serviceInstances",
2278 "tenantName": "k8stenant",
2279 "cloudApiRequests": [],
2280 "requestURI": "6a369c8e-d492-4ab5-a107-46804eeb7873",
2283 "href": "http://infra:30277/infraActiveRequests/6a369c8e-d492-4ab5-a107-46804eeb7873"
2285 "infraActiveRequests": {
2286 "href": "http://infra:30277/infraActiveRequests/6a369c8e-d492-4ab5-a107-46804eeb7873"
2292 Progress can be followed also with `SO Monitoring`_ dashboard.
2294 .. 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
2297 You can finally terminate this instance (now or later) with another call:
2299 **Postman -> LCM -> 5. [SO] Service Delete**
2301 Second instance Instantiation
2302 +++++++++++++++++++++++++++++
2304 To finally verify that all the work done within this demo, it should be possible to instantiate second vFW instance successfully.
2306 Trigger new instance createion. You can use previous call or a separate one that will utilize profile templating mechanism implemented in CBA:
2308 **Postman -> LCM -> 6. [SO] Self-Serve Service Assign & Activate - Second**
2310 3-3 Results and Logs
2311 ....................
2313 Now multiple instances of Kubernetes variant of vFW are running in target VIM (KUD deployment).
2315 .. figure:: files/vFW_CNF_CDS/vFW_Instance_In_Kubernetes.png
2318 vFW Instance In Kubernetes
2320 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.
2322 **Postman -> Instantiation verification**
2324 Execute example Postman queries and check example section to see the valid results.
2326 ========================== =================
2327 Verify Target Postman query
2328 -------------------------- -----------------
2329 Service Instances in AAI **Postman -> Instantiation verification -> [AAI] List Service Instances**
2330 Service Instances in MDSAL **Postman -> Instantiation verification -> [SDNC] GR-API MD-SAL Services**
2331 K8S Instances in KUD **Postman -> Instantiation verification -> [K8splugin] List Instances**
2332 ========================== =================
2334 .. note:: "[AAI] List vServers <Empty>" Request won't return any vserver info from AAI, as currently such information are not provided during instantiation process.
2337 Query also directly from VIM:
2339 FIXME - needs updated output with newest naming policy
2344 ubuntu@kud-host:~$ kubectl get pods,svc,networks,cm,network-attachment-definition,deployments
2345 NAME READY STATUS RESTARTS AGE
2346 pod/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f-7cfb9949d9-8b5vg 1/1 Running 0 22s
2347 pod/vfw-19571429-4af4-49b3-af65-2eb1f97bba43-75cd7c6f76-4gqtz 1/1 Running 0 11m
2348 pod/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-f4485d485-pln8m 1/1 Running 0 11m
2349 pod/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-6f8cff54d-dvw4j 1/1 Running 0 32s
2350 pod/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-5879c56fd-q59l7 2/2 Running 0 11m
2351 pod/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-5889b7455-96j9d 2/2 Running 0 30s
2353 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
2354 service/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-management-api NodePort 10.244.43.245 <none> 2831:30831/TCP 11m
2355 service/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-management-api NodePort 10.244.1.45 <none> 2831:31831/TCP 33s
2356 service/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-darkstat-ui NodePort 10.244.16.187 <none> 667:30667/TCP 11m
2357 service/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-darkstat-ui NodePort 10.244.20.229 <none> 667:31667/TCP 30s
2360 network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-management-network 40s
2361 network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-protected-network 40s
2362 network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-unprotected-network 40s
2363 network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-management-network 11m
2364 network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-protected-network 11m
2365 network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-unprotected-network 11m
2368 configmap/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f-configmap 6 22s
2369 configmap/vfw-19571429-4af4-49b3-af65-2eb1f97bba43-configmap 6 11m
2370 configmap/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-configmap 6 11m
2371 configmap/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-configmap 6 33s
2372 configmap/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-configmap 2 11m
2373 configmap/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-configmap 2 30s
2376 networkattachmentdefinition.k8s.cni.cncf.io/55118b80-8470-4c99-bfdf-d122cd412739-ovn-nat 40s
2377 networkattachmentdefinition.k8s.cni.cncf.io/567cecc3-9692-449e-877a-ff0b560736be-ovn-nat 11m
2379 NAME READY UP-TO-DATE AVAILABLE AGE
2380 deployment.extensions/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f 1/1 1 1 22s
2381 deployment.extensions/vfw-19571429-4af4-49b3-af65-2eb1f97bba43 1/1 1 1 11m
2382 deployment.extensions/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e 1/1 1 1 11m
2383 deployment.extensions/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26 1/1 1 1 33s
2384 deployment.extensions/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14 1/1 1 1 11m
2385 deployment.extensions/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b 1/1 1 1 30s
2388 Component Logs From The Execution
2389 +++++++++++++++++++++++++++++++++
2391 All logs from the use case execution are here:
2393 :download:`logs <files/vFW_CNF_CDS/logs.zip>`
2395 - `so-bpmn-infra_so-bpmn-infra_debug.log`
2396 - SO openstack adapter
2397 - `sdnc_sdnc_karaf.log`
2399 From karaf.log all requests (payloads) to CDS can be found by searching following string:
2401 ``'Sending request below to url http://cds-blueprints-processor-http:8080/api/v1/execution-service/process'``
2403 - `cds-blueprints-processor_cds-blueprints-processor_POD_LOG.log`
2404 - `multicloud-k8s_multicloud-k8s_POD_LOG.log`
2409 In case more detailed logging is needed, here's instructions how to setup DEBUG logging for few components.
2415 kubectl -n onap exec -it onap-sdnc-0 -c sdnc /opt/opendaylight/bin/client log:set DEBUG
2418 - CDS Blueprint Processor
2423 kubectl -n onap edit configmap onap-cds-blueprints-processor-configmap
2425 # Edit logback.xml content change root logger level from info to debug.
2426 <root level="debug">
2427 <appender-ref ref="STDOUT"/>
2430 # Delete the Pods to make changes effective
2431 kubectl -n onap delete pods -l app=cds-blueprints-processor
2433 PART 4 - Summary and Future improvements needed
2434 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2436 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.
2438 CNF application in vFW (Helm charts) were divided to multiple Helm charts comply with vf-module structure of a Heat based VNF.
2440 Future development areas for this use case and in general for CNF support could be:
2442 - Automate manual initialization steps in to Robot init. Now all was done with Postman or manual step on command line.
2443 - Automate use case in ONAP daily CI
2444 - Include Closed Loop part of the vFW demo.
2445 - Use multicloud/k8S API v2. Also consider profile concept future.
2446 - 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.
2447 - TOSCA based service and xNF models instead of dummy Heat wrapper. Won't work directly with current vf-module oriented SO workflows.
2448 - vFW service with Openstack VNF and Kubernetes CNF
2449 - Post instantiation configuration with Day 2 configuration APIs of multicloud/k8S API
2450 - Auto generation of instantiation specific helm resources in CDS and their population through profiles
2453 Multiple lower level bugs/issues were also found during use case development
2455 - Distribution of Helm package directly from onboarding package `SDC-2776`_
2456 - CDS: UAT testing is broken `CCSDK-2155`_
2458 .. _ONAP Deployment Guide: https://docs.onap.org/en/frankfurt/submodules/oom.git/docs/oom_quickstart_guide.html#quick-start-label
2459 .. _CDS Modeling Concepts: https://wiki.onap.org/display/DW/Modeling+Concepts
2460 .. _vLB use-case: https://wiki.onap.org/pages/viewpage.action?pageId=71838898
2461 .. _vFW_CNF_CDS Model: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS?h=frankfurt
2462 .. _vFW CDS Dublin: https://wiki.onap.org/display/DW/vFW+CDS+Dublin
2463 .. _vFW CBA Model: https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/service-blueprint/vFW?h=frankfurt
2464 .. _vFW_Helm Model: https://git.onap.org/multicloud/k8s/tree/kud/demo/firewall?h=elalto
2465 .. _vFW_NextGen: https://git.onap.org/demo/tree/heat/vFW_NextGen?h=elalto
2466 .. _vFW EDGEX K8S: https://onap.readthedocs.io/en/elalto/submodules/integration.git/docs/docs_vfw_edgex_k8s.html
2467 .. _vFW EDGEX K8S In ONAP Wiki: https://wiki.onap.org/display/DW/Deploying+vFw+and+EdgeXFoundry+Services+on+Kubernets+Cluster+with+ONAP
2468 .. _KUD readthedocs: https://docs.onap.org/en/frankfurt/submodules/multicloud/k8s.git/docs
2469 .. _KUD in Wiki: https://wiki.onap.org/display/DW/Kubernetes+Baremetal+deployment+setup+instructions
2470 .. _Multicloud k8s gerrit: https://gerrit.onap.org/r/q/status:open+project:+multicloud/k8
2471 .. _KUD subproject in github: https://github.com/onap/multicloud-k8s/tree/master/kud
2472 .. _KUD Jenkins ci/cd verification: https://jenkins.onap.org/job/multicloud-k8s-master-kud-deployment-verify-shell/
2473 .. _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
2474 .. _SO Monitoring: https://wiki.onap.org/display/DW/SO+Monitoring+User+Guide
2475 .. _Jira Epic: https://jira.onap.org/browse/INT-1184
2476 .. _Data Dictionary: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba-dd.json?h=frankfurt
2477 .. _Helm Healer: https://git.onap.org/oom/offline-installer/tree/tools/helm-healer.sh
2478 .. _CDS UAT Testing: https://wiki.onap.org/display/DW/Modeling+Concepts
2479 .. _postman.zip: files/vFW_CNF_CDS/postman.zip
2480 .. _logs.zip: files/vFW_CNF_CDS/logs.zip
2481 .. _SDC-2776: https://jira.onap.org/browse/SDC-2776
2482 .. _MULTICLOUD-941: https://jira.onap.org/browse/MULTICLOUD-941
2483 .. _CCSDK-2155: https://jira.onap.org/browse/CCSDK-2155
2484 .. _infra_workload: https://docs.onap.org/projects/onap-multicloud-framework/en/latest/specs/multicloud_infra_workload.html?highlight=multicloud
2485 .. _SDNC-1116: https://jira.onap.org/browse/SDNC-1116
2486 .. _SO-2727: https://jira.onap.org/browse/SO-2727
2487 .. _SDNC-1109: https://jira.onap.org/browse/SDNC-1109
2488 .. _SDC-2776: https://jira.onap.org/browse/SDC-2776
2489 .. _INT-1255: https://jira.onap.org/browse/INT-1255
2490 .. _SDNC-1130: https://jira.onap.org/browse/SDNC-1130