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`_
15 - Automation Scripts: `vFW_CNF_CDS Automation`_
19 This use case is a combination of `vFW CDS Dublin`_ and `vFW EDGEX K8S`_ use cases and it is continously improved since Frankfurt release. 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`_.
21 This use case shows how to onboard helm packages and to instantiate them with help of ONAP. Following improvements were made in the vFW CNF Use Case:
23 - vFW Kubernetes Helm charts support overrides (previously mostly hardcoded values)
24 - SDC accepts Onboarding Package with many helm packages what allows to keep decomposition of service instance similar to `vFW CDS Dublin`_
25 - Compared to `vFW EDGEX K8S`_ use case **MACRO** workflow in SO is used instead of VNF a'la carte workflow
26 - No VNF data preloading used, instead resource-assignment feature of CDS is used
27 - CDS is used to resolve instantiation time parameters (Helm overrides)
28 * IP addresses with IPAM
29 * Unique names for resources with ONAP naming service
30 * CDS is used to create and upload **multicloud/k8s profile** as part of instantiation flow
31 - Combined all models (Heat, Helm, CBA) in to same git repo and a created single onboarding package `vFW_CNF_CDS Model`_
32 - vFW CNF status is monitored prior to the completion of the instantiation process.
33 - It is possible to not only provide overrides for Helm packages but we can modify Helm packages before instantiation or we can modify CNF after its deployment
34 - Use case does not contain Closed Loop part of the vFW demo.
36 All changes to related ONAP components and Use Case can be found in the following tickets:
46 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.
48 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.
50 Demo git directory has also `Data Dictionary`_ file (CDS model time resource) included.
52 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.
54 Following table describes all the source models to which this demo is based on.
56 =============== ================= ===========
57 Model Git reference Description
58 --------------- ----------------- -----------
59 Heat `vFW_NextGen`_ Heat templates used in original vFW demo but split into multiple vf-modules
60 Helm `vFW_Helm Model`_ Helm templates used in `vFW EDGEX K8S`_ demo
61 CDS model `vFW CBA Model`_ CDS CBA model used in `vFW CDS Dublin`_ demo
62 =============== ================= ===========
64 .. note:: Since the Guilin release `vFW_CNF_CDS Model`_ contains sources that allow to model and instantiate CNF with VNF/Heat orchestration approach (Frankfurt) and with native Helm orchestration approach (Guilin and beyond). VNF/Heat orchestration approach is deprecated and will not be enhanced in the future. Please follow README.txt description and further documentation here to generate and select appropriate onboarding package which will leverage appropriate SO orchestration path.
66 Since Honolulu release vFW CNF use case supports three different scenarios where different capabilities of CNF Orchestration in ONAP can be experimented:
68 .. figure:: files/vFW_CNF_CDS/scenarios.png
74 - Scenario 1: simple deployment of vFW CNF instance
75 - Scenario 2: deployment of vFW CNF instance with enrichment of the Helm deployment with profiling mechanism
76 - Scenario 3: deployment of vFW CNF instance with Day2 configuration applied and CNF status checked as a part of a config-deploy operation
78 The 3rd scenario presents the most comprehensive way of managing the CNF in ONAP, including Day 0/1/2 operations. It shows also how to combine in the Day2 operation information for the AAI and SDNC MDSAL. All scenarios can be supported by execution of the dedicated Healthcheck workflow `3-5 Verification of the CNF Status`_.
80 Modeling of Onboarding Package/Helm
81 ...................................
83 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.
85 The Jakarta version of the `vFW_CNF_CDS Model`_ contains files required to create **VSP onboarding packages in Helm Native format** where each Helm package is standalone and is natively understood in consequence by SO. The **Dummy Heat** (available in Frankfurt release already) one that considers association of each Helm package with dummy heat templates since Jakarta is not a prt of the vFW CNF demo. If you are interested to see how to onboard and orchestrate the CNF using the **Dummy Heat** approach, please open the Istanbul version of the documentation. The VSP Helm packages are matched to the vf-module concept, so basically each Helm application after instantiation is visible to ONAP as a separate vf-module. The **Native Helm** format for onboarding has **crucial** role in the further orchestration approach applied for Helm package instantiation as it leverages the **CNF Adapter** and it populates k8s resource information to AAI what plays significant role in the Day operation for CNFs, including closed-loop automation with Prometheus. Read more in `3-1 CNF Orchestration Paths in ONAP`_
87 Produced **Native Helm** VSP onboarding package `Creating Onboarding Package`_ format has following MANIFEST file (package_native/MANIFEST.json). The Helm package is delivered as HELM package through SDC and SO. The *isBase* flag of HELM artifact is ignored by SDC but in the manifest one HELM or HEAT artifacts must be defined as isBase = true. If both HEAT and HELM are present in the same manifest file the base one must be always one of HELM artifacts. Moreover, the name of HELM type artifact **MUST** match the specified pattern: *helm_<some_name>* and the HEAT type artifacts, if present in the same manifest, cannot contain keyword *helm*. These limitations are a consequence of current limitations of the SDC onboarding and VSP validation engine and will be adresssed in the future releases.
92 "name": "virtualFirewall",
97 "type": "CONTROLLER_BLUEPRINT_ARCHIVE"
100 "file": "helm_base_template.tgz",
105 "file": "helm_vfw.tgz",
110 "file": "helm_vpkg.tgz",
115 "file": "helm_vsn.tgz",
122 .. note:: CDS model (CBA package) is delivered as SDC supported own type CONTROLLER_BLUEPRINT_ARCHIVE but the current limitation of VSP onbarding forces to use the artifact name *CBA.zip* to automaticaly recognize CBA as a CONTROLLER_BLUEPRINT_ARCHIVE.
127 CDS plays a crucial role in the process of CNF instantiation and is responsible for delivery of instantiation parameters, CNF customization, configuration of CBF after the deployment and may be used in the process of CNF status verification.
129 Creating CDS model was the core of the use case work and also the most difficult and time consuming part. Current template used by use-case should be easily reusable for anyone. Once CDS GUI will be fully working, we think that CBA development should be much easier. For CBA structure reference, please visit it's documentation page `CDS Documentation`_.
131 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.
133 Base on this example there are demonstrated following features of CDS and CBA model
135 - resource assignment string, integer and json types
136 - sourcing of resolved value on vf-module level from vnf level assignment
137 - extracting data from AAI and MD-SAL during the resource assignment
138 - custom resource assignment with Kotlin script
139 - templating of the vtl files
140 - building of imperative workflows
141 - utilization of on_succes and on_failure event in imperative workflow
142 - handling of the failure in the workflow
143 - implementation of custom workflow logic with Kotlin script
144 - example of config-assign and config-deploy operation decomposed into many steps
145 - complex parametrization of config deploy operation
146 - combination and aggregation of AAI and MD-SAL data in config-assign and config-deploy operations
148 The prepared CBA model demonstrates also how to utilize CNF specific features of CBA, suited for the deployment of CNF with k8splugin in ONAP:
150 - building and upload of k8s profile template into k8splugin
151 - building and upload of k8s configuration template into k8splugin
152 - parametrization and creation of configuration instance from configuration template
153 - validation of CNF status with Kotlin script
154 - execution of the CNF healtcheck
156 As K8S application is split into multiple Helm packages to match vf-modules, CBA modeling follows the same and for each vf-module there's own template in CBA package. The **Native Helm** approach, requires the Helm artifact names to star with *helm_* prefix, in the same way like names of artifacts in the MANIFEST file of VSP differs. The **Native Helm** artifacts' list is following:
161 "helm_base_template-template" : {
162 "type" : "artifact-template-velocity",
163 "file" : "Templates/base_template-template.vtl"
165 "helm_base_template-mapping" : {
166 "type" : "artifact-mapping-resource",
167 "file" : "Templates/base_template-mapping.json"
169 "helm_vpkg-template" : {
170 "type" : "artifact-template-velocity",
171 "file" : "Templates/vpkg-template.vtl"
173 "helm_vpkg-mapping" : {
174 "type" : "artifact-mapping-resource",
175 "file" : "Templates/vpkg-mapping.json"
177 "helm_vfw-template" : {
178 "type" : "artifact-template-velocity",
179 "file" : "Templates/vfw-template.vtl"
181 "helm_vfw-mapping" : {
182 "type" : "artifact-mapping-resource",
183 "file" : "Templates/vfw-mapping.json"
186 "type" : "artifact-template-velocity",
187 "file" : "Templates/vnf-template.vtl"
190 "type" : "artifact-mapping-resource",
191 "file" : "Templates/vnf-mapping.json"
193 "helm_vsn-template" : {
194 "type" : "artifact-template-velocity",
195 "file" : "Templates/vsn-template.vtl"
197 "helm_vsn-mapping" : {
198 "type" : "artifact-mapping-resource",
199 "file" : "Templates/vsn-mapping.json"
203 SO requires for instantiation name of the profile in the parameter: *k8s-rb-profile-name* and name of the release of thr application: *k8s-rb-instance-release-name*. The latter one, when not specified, will be replaced with combination of profile name and vf-module-id for each Helm instance/vf-module instantiated. Both values can be found in vtl templates dedicated for vf-modules.
205 CBA offers possibility of the automatic generation and upload to multicloud/k8s plugin the RB profile content. RB profile is required if you want to deploy your CNF into k8s namesapce other than *default*. Also, if you want to ensure particular templating of your Helm charts, specific to particular version of the cluster into which Helm packages will deployed on, profile is used to specify the version of your cluster.
207 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 modify existing k8s helm templates for each create CNF instance. It opens another level of CNF customization, much more than customization of the Helm package with override values. K8splugin offers also *default* profile without content, for default namespace and default cluster version.
214 values: "override_values.yaml"
216 - filepath: resources/deployment.yaml
217 chartpath: templates/deployment.yaml
220 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 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.
222 In order to support generation and upload of profile, our vFW CBA model has enhanced **resource-assignment** workflow which contains additional step: **profile-upload**. It leverages dedicated functionality introduced in Guilin release that can be used to upload predefined profile or to generate and upload content of the profile with Velocity templating mechanism.
226 "resource-assignment": {
228 "resource-assignment": {
229 "description": "Resource Assign Workflow",
230 "target": "resource-assignment",
233 "call_operation": "ResourceResolutionComponent.process"
241 "description": "Generate and upload K8s Profile",
242 "target": "k8s-profile-upload",
245 "call_operation": "ComponentScriptExecutor.process"
251 .. note:: In the Frankfurt release profile upload was implemented as a custom Kotlin script included into the CBA. It was responsible for upload of K8S profile into multicloud/k8s plugin. It is still a good example of the integration of Kotlin scripting into the CBA. For those interested in this functionaliy we recommend to look into the `Frankfurt CBA Definition`_ and `Frankfurt CBA Script`_. Since Honolulu we introduce more advanced use of the Kotlin script for verification of the CNF status or custom resolution of complex parameters over Kotlin script - both can be found in the further part of the documentation.
253 In our example for vPKG helm package we may select *vfw-cnf-cds-vpkg-profile* profile that is included into CBA as a folder. Profile generation step uses Velocity templates processing embedded CDS functionality on its basis ssh port number (specified in the SO request as *vpg-management-port*).
258 "name": "vpg-management-port",
260 "description": "The number of node port for ssh service of vpg",
264 "input-param": false,
265 "dictionary-name": "vpg-management-port",
266 "dictionary-source": "default",
270 *vpg-management-port* can be included directly into the helm template and such template will be included into vPKG helm package in time of its instantiation.
277 name: {{ .Values.vpg_name_0 }}-ssh-access
279 vnf-name: {{ .Values.vnf_name }}
280 vf-module-name: {{ .Values.vpg_name_0 }}
281 release: {{ .Release.Name }}
282 chart: {{ .Chart.Name }}
287 nodePort: ${vpg-management-port}
289 vf-module-name: {{ .Values.vpg_name_0 }}
290 release: {{ .Release.Name }}
291 chart: {{ .Chart.Name }}
293 .. warning:: The port value is of Integer type and CDS resolves it as an integer. If the resolved values are returned to SO during the resource resolution phase they are being passed to k8splugin back only as a strings. In consequence, Integer values are passed to the Instantiation API as a strings and then they have go be converted in the helm template to the integer. In order to avoid such conversion it is better to customize override values with Integers in the profile and to skip return of this parameters in the resource resolution phase (they should not be included in the .vtl files).
295 The mechanism of profile generation and upload requires specific node teamplate in the CBA definition. In our case, it comes with the declaration of two profiles: one static *vfw-cnf-cds-base-profile* in a form of an archive and the second complex *vfw-cnf-cds-vpkg-profile* in a form of a folder for processing and profile generation. Below is the example of the definition of node type for execution of the profile upload operation.
299 "k8s-profile-upload": {
300 "type": "component-k8s-profile-upload",
302 "K8sProfileUploadComponent": {
306 "artifact-prefix-names": {
307 "get_input": "template-prefix"
309 "resource-assignment-map": {
311 "resource-assignment",
321 "vfw-cnf-cds-base-profile": {
322 "type": "artifact-k8sprofile-content",
323 "file": "Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz"
325 "vfw-cnf-cds-vpkg-profile": {
326 "type": "artifact-k8sprofile-content",
327 "file": "Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile"
329 "vfw-cnf-cds-vpkg-profile-mapping": {
330 "type": "artifact-mapping-resource",
331 "file": "Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json"
336 Artifact file determines a place of the static profile or the content of the complex profile. In the latter case we need a pair of profile folder and mapping file with a declaration of the parameters that CDS needs to resolve first, before the Velocity templating is applied to the .vtl files present in the profile content. After Velocity templating the .vtl extensions will be dropped from the file names. The embedded mechanism will include in the profile only files present in the profile MANIFEST file that needs to contain the list of final names of the files to be included into the profile. The figure below shows the idea of profile templating.
338 .. figure:: files/vFW_CNF_CDS/profile-templating.png
341 K8s Profile Templating
343 SO requires for instantiation name of the profile in the parameter: *k8s-rb-profile-name*. The *component-k8s-profile-upload* that stands behind the profile uploading mechanism has input parameters that can be passed directly (checked in the first order) or can be taken from the *resource-assignment-map* parameter which can be a result of associated *component-resource-resolution* result, like in our case their values are resolved on vf-module level resource assignment. The *component-k8s-profile-upload* inputs are following:
345 - k8s-rb-definition-name [string] - (mandatory) the name under which RB definition was created - **VF Module Model Invariant ID** in ONAP
346 - k8s-rb-definition-version [string] - (mandatory) the version of created RB definition name - **VF Module Model Customization ID** in ONAP
347 - k8s-rb-profile-name [string] - (mandatory) the name of the profile under which it will be created in k8s plugin. Other parameters are required only when profile must be uploaded because it does not exist yet
348 - k8s-rb-profile-source [string] - the source of profile content - name of the artifact of the profile. If missing *k8s-rb-profile-name* is treated as a source
349 - k8s-rb-profile-namespace [string] - (mandatory) the k8s namespace name associated with profile being created
350 - k8s-rb-profile-kubernetes-version [string] - the version of the cluster on which application will be deployed - it may impact the helm templating process like selection of the api versions for resources so it should match the version of k8s cluster in which resources are bing deployed.
351 - k8s-rb-profile-labels [json] - the extra labels (label-name: label-value) to add for each k8s resource created for CNF in the k8s cluster (since Jakarta release).
352 - k8s-rb-profile-extra-types [list<json>] - the list of extra k8s types that should be returned by StatusAPI. It may be usefull when k8s resources associated with CNF instance are created outside of the helm package (i.e. by k8s operator) but should be treated like resources of CNF. To make it hapens such resources should have the instance label *k8splugin.io/rb-instance-id* what may be assured by such tools like *kyverno*. Each extra type json object needs *Group*, *Version* and *Kind* attributes. (since Jakarta release).
353 - resource-assignment-map [json] - result of the associated resource assignment step - it may deliver values of inputs if they are not specified directly
354 - artifact-prefix-names [list<string>] - (mandatory) the list of artifact prefixes like for resource-assigment step in the resource-assigment workflow or its subset
356 In the SO request user can pass parameter of name *k8s-rb-profile-name* which in our case may have value: *vfw-cnf-cds-base-profile*, *vfw-cnf-cds-vpkg-profile* or *default*. The *default* profile does not contain any content inside and allows instantiation of CNF without the need to define and upload any additional profiles. *vfw-cnf-cds-vpkg-profile* has been prepared to test instantiation of the second modified vFW CNF instance.
358 K8splugin allows to specify override parameters (similar to --set behavior of helm client) to instantiated resource bundles. This allows for providing dynamic parameters to instantiated resources without the need to create new profiles for this purpose. This mechanism should be used with *default* profile but may be used also with any custom profile.
360 The overall flow of helm overrides parameters processing is visible on following figure. When *rb definition* (helm package) is being instantiated for specified *rb profile* K8splugin combines override values from the helm package, *rb profile* and from the instantiation request - in the respective order. It means that the value from the instantiation request (SO request input or CDS resource assignment result) has a precedence over the value from the *rb profile* and value from the *rb profile* has a precedence over the helm package default override value. Similarly, profile can contain resource files that may extend or ammend the existing files for the original helm package content.
362 .. figure:: files/vFW_CNF_CDS/helm-overrides.png
365 The overall flow of helm data processing
367 Both profile content (4) like the instantiation request values (5) can be generated during the resource assignment process according to its definition for CBA associated with helm package. CBA may generate i.e. names, IP addresses, ports and can use this information to produce the *rb-profile* (3) content. Finally, all three sources of override values, temnplates and additional resources files are merged together (6) by K8splugin in the order exaplained before.
369 .. figure:: files/vFW_CNF_CDS/helm-overrides-steps.png
372 The steps of processing of helm data with help of CDS
374 Both profile content (4) like the instantiation request values (5) can be generated during the resource assignment process according to its definition for CBA associated with helm package. CBA may generate i.e. names, IP addresses, ports and can use this information to produce the *rb-profile* (3) content. Finally, all three sources of override values, temnplates and additional resources files are merged together (6) by K8splugin in the order exaplained before.
376 Besides the deployment of Helm application the CBA of vFW demonstrates also how to use deicated features for config-assign (7) and config-deploy (8) operations. In the use case, *config-assign* and *config-deploy* operations deal mainly with creation and instantiation of configuration template for k8s plugin. The configuration template has a form of Helm package. When k8s plugin instantiates configuration, it creates or may replace existing resources deployed on k8s cluster. In our case the configuration template is used to provide alternative way of upload of the additional ssh-service but it coud be used to modify configmap of vfw or vpkg vf-modules.
378 In order to provide configuration instantiation capability standard *config-assign* and *config-deploy* workflows have been changed into imperative workflows with first step responsible for collection of information for configuration templating and configuration instantiation. The source of data for this operations is AAI, MDSAL with data for vnf and vf-modules as *config-assign* and *config-deploy* does not receive dedicated input parameters from SO. In consequence both operations need to source from *resource-assignment* phase and data placed in the AAI and MDSAL.
380 vFW CNF *config-assign* workflow is following:
387 "description": "Gather necessary input for config template upload",
388 "target": "config-setup-process",
391 "call_operation": "ResourceResolutionComponent.process"
399 "description": "Generate and upload K8s config template",
400 "target": "k8s-config-template",
403 "call_operation": "K8sConfigTemplateComponent.process"
409 vFW CNF *config-deploy* workflow is following:
416 "description": "Gather necessary input for config init and status verification",
417 "target": "config-setup-process",
420 "call_operation": "ResourceResolutionComponent.process"
428 "description": "Activate K8s config template",
429 "target": "k8s-config-apply",
432 "call_operation": "K8sConfigTemplateComponent.process"
436 "status-verification-script"
441 In our example configuration template for vFW CNF is a helm package that contains the same resource that we can find in the vPKG *vfw-cnf-cds-vpkg-profile* profile - extra ssh service. This helm package contains Helm encapsulation for ssh-service and the values.yaml file with declaration of all the inputs that may parametrize the ssh-service. The configuration templating step leverages the *component-k8s-config-template* component that prepares the configuration template and uploads it to k8splugin. In consequence, it may be used later on for instatiation of the configuration.
443 In this use case we have two options with *ssh-service-config* and *ssh-service-config-customizable* as a source of the same configuration template. In consequence, or we take a complete template or we have have the template folder with the content of the helm package and CDS may perform dedicated resource resolution for it with templating of all the files with .vtl extensions. The process is very similar to the one describe for profile upload functionality.
447 "k8s-config-template": {
448 "type": "component-k8s-config-template",
450 "K8sConfigTemplateComponent": {
454 "artifact-prefix-names": [
457 "resource-assignment-map": {
459 "config-setup-process",
463 "config-deploy-setup"
472 "ssh-service-config": {
473 "type": "artifact-k8sconfig-content",
474 "file": "Templates/k8s-configs/ssh-service.tar.gz"
476 "ssh-service-config-customizable": {
477 "type": "artifact-k8sconfig-content",
478 "file": "Templates/k8s-configs/ssh-service-config"
480 "ssh-service-config-customizable-mapping": {
481 "type": "artifact-mapping-resource",
482 "file": "Templates/k8s-configs/ssh-service-config/ssh-service-mapping.json"
487 The *component-k8s-config-template* that stands behind creation of configuration template has input parameters that can be passed directly (checked in the first order) or can be taken from the *resource-assignment-map* parameter which can be a result of associated *component-resource-resolution* result, like in vFW CNF use case their values are resolved on vf-module level dedicated for *config-assign* and *config-deploy* resource assignment step. The *component-k8s-config-template* inputs are following:
489 - k8s-rb-definition-name [string] - (mandatory) the name under which RB definition was created - **VF Module Model Invariant ID** in ONAP
490 - k8s-rb-definition-version [string] - (mandatory) the version of created RB definition name - **VF Module Model Customization ID** in ONAP
491 - k8s-rb-config-template-name [string] - (mandatory) the name of the configuration template under which it will be created in k8s plugin. Other parameters are required only when configuration template must be uploaded because it does not exist yet
492 - k8s-rb-config-template-source [string] - the source of config template content - name of the artifact of the configuration template. When missing, the main definition helm package will be used as a configuration template source (since Jakarta release).
493 - resource-assignment-map [json] - result of the associated resource assignment step - it may deliver values of inputs if they are not specified directly
494 - artifact-prefix-names [list<string>] - (mandatory) the list of artifact prefixes like for resource-assigment step in the resource-assigment workflow or its subset
496 In our case the *component-k8s-config-template* component receives all the inputs from the dedicated resource-assignment process *config-setup* that is responsible for resolution of all the inputs for configuration templating. This process generates data for *helm_vpkg* prefix and such one is specified in the list of prefixes of the configuration template component. It means that configuration template will be prepared only for vPKG function.
500 "k8s-config-apply": {
501 "type": "component-k8s-config-value",
503 "K8sConfigValueComponent": {
507 "artifact-prefix-names": [
510 "k8s-config-operation-type": "create",
511 "resource-assignment-map": {
513 "config-setup-process",
517 "config-deploy-setup"
526 "ssh-service-default": {
527 "type": "artifact-k8sconfig-content",
528 "file": "Templates/k8s-configs/ssh-service-config/values.yaml"
530 "ssh-service-config": {
531 "type": "artifact-k8sconfig-content",
532 "file": "Templates/k8s-configs/ssh-service-values/values.yaml.vtl"
534 "ssh-service-config-mapping": {
535 "type": "artifact-mapping-resource",
536 "file": "Templates/k8s-configs/ssh-service-values/ssh-service-mapping.json"
542 The *component-k8s-config-value* that stands behind creation of configuration instance has input parameters that can be passed directly (checked in the first order) or can be taken from the *resource-assignment-map* parameter which can be a result of associated *component-resource-resolution* result, like in vFW CNF use case their values are resolved on vf-module level dedicated for *config-assign* and *config-deploy*'s' resource-assignment step. The *component-k8s-config-value* inputs are following:
544 - k8s-rb-config-name [string] - (mandatory) the name of the configuration template under which it will be created in k8s plugin. Other parameters are required only when configuration template must be uploaded because it does not exist yet
545 - k8s-rb-config-template-name [string] - (mandatory) the name of the configuration template under which it will be created in k8s plugin. Other parameters are required only when configuration template must be uploaded because it does not exist yet
546 - k8s-rb-config-value-source [string] - the source of config template content - name of the artifact of the configuration template. If missing *k8s-rb-config-name* is treated as a source
547 - k8s-rb-config-version [string] - the version of the configuration to restore during the *rollback* operation. First configuratino after *create* has version *1* and new ones, after *update* will have version of the following numbers. When *rollback* operation is performed all previous versions on the path to the desired one are being restored one, by one. (since Jakarta)
548 - k8s-instance-id [string] - (mandatory) the identifier of the rb instance for which the configuration should be applied
549 - k8s-config-operation-type [string] - the type of the configuration operation to perform: *create*, *update*, *rollback*, *delete* or *delete_config*. By default *create* operation is performed. *rollback* and *delete_config* types are present since Jakarta release. The *update* operation creates new version of the configuration. *delete* operation creates also new version of configuratino that deletes all the resources in k8s from the cluster. *delete_config* operation aims to delete configuration entirely but it does not delete or update any resources associated with the configuration.
550 - resource-assignment-map [json] - result of the associated resource assignment step - it may deliver values of inputs if they are not specified directly
551 - artifact-prefix-names [list<string>] - (mandatory) the list of artifact prefixes like for resource-assigment step in the resource-assigment workflow or its subset
553 Like for the configuration template, the *component-k8s-config-value* component receives all the inputs from the dedicated resource-assignment process *config-setup* that is responsible for resolution of all the inputs for configuration. This process generates data for *helm_vpkg* prefix and such one is specified in the list of prefixes of the configuration values component. It means that configuration instance will be created only for vPKG function (component allows also update or delete of the configuration but in the vFW CNF case it is used only to create configuration instance).
555 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.
557 .. note:: CBA of vFW CNF use case is already enriched and VSP of vFW CNF has CBA included inside. In conequence, when VSP is being onboarded into SDC and service is being distributed, CBA is uploaded into CDS. Anyway, CDS contains in the starter dictionary all data dictionary values used in the use case and enrichment of CBA should work as well.
559 Instantiation Overview
560 ----------------------
562 .. note:: Since Guilin release use case is equipped with automated method **<AUTOMATED>** with python scripts to replace Postman method **<MANUAL>** used in Frankfurt. Nevertheless, Postman collection is good to understand the entire process. If a user selects to follow Postman collection, then automation scripts **must not** be used. **For the entire process use only scripts or only Postman collection**. Both options are described in the further steps of this instruction.
564 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.
566 .. figure:: files/vFW_CNF_CDS/Instantiation_topology.png
569 vFW CNF CDS Use Case Runtime interactions.
571 PART 1 - ONAP Installation
572 ~~~~~~~~~~~~~~~~~~~~~~~~~~
574 1-1 Deployment components
575 .........................
577 In order to run the vFW_CNF_CDS use case, we need ONAP Jakarta Release (or later) with at least following components:
579 ======================================================= ===========
580 ONAP Component name Describtion
581 ------------------------------------------------------- -----------
582 AAI Required for Inventory Cloud Owner, Customer, Owning Entity, Service, Generic VNF, VF Module
583 SDC VSP, VF and Service Modeling of the CNF
584 DMAAP Distribution of the onboarding package including CBA to all ONAP components
585 SO Required for Macro Orchestration using the generic building blocks
586 CDS Resolution of cloud parameters including Helm override parameters for the CNF. Creation of the multicloud/k8s profile for CNF instantion. Creation of configuration template and its instantiation
587 SDNC (needs to include netbox and Naming Generation mS) Provides GENERIC-RESOURCE-API for cloud Instantiation orchestration via CDS.
588 Policy Used to Store Naming Policy
589 AAF Used for Authentication and Authorization of requests
590 Portal Required to access SDC.
591 MSB Exposes multicloud interfaces used by SO.
592 Multicloud K8S plugin part used to pass SO instantiation requests to external Kubernetes cloud region.
593 Contrib Chart containing multiple external components. Out of those, we only use Netbox utility in this use-case for IPAM
594 Robot Optional. Can be used for running automated tasks, like provisioning cloud customer, cloud region, service subscription, etc ..
595 Shared Cassandra DB Used as a shared storage for ONAP components that rely on Cassandra DB, like AAI
596 Shared Maria DB Used as a shared storage for ONAP components that rely on Maria DB, like SDNC, and SO
597 ======================================================= ===========
602 In order to deploy such an instance, follow the `ONAP Deployment Guide`_
604 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.
606 **override.yaml** file where enabled: true is set for each component needed in demo (by default all components are disabled).
641 Then deploy ONAP with Helm with your override file.
645 helm deploy onap local/onap --namespace onap -f ~/override.yaml
647 In case redeployment needed `Helm Healer`_ could be a faster and convenient way to redeploy.
651 helm-healer.sh -n onap -f ~/override.yaml -s /dockerdata-nfs --delete-all
653 Or redeploy (clean re-deploy also data removed) just wanted components (Helm releases), cds in this example.
657 helm-healer.sh -f ~/override.yaml -s /dockerdata-nfs/ -n onap -c onap-cds
659 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*.
665 for comp in {aaf,aai,dmaap,msb,multicloud,policy,portal,sdc,sdnc,so}; do
666 if ! ./ete-k8s.sh onap health-$comp; then
670 if [ -n "$failed" ]; then
671 echo "These components failed: $failed"
674 echo "Healthcheck successful"
678 And check status of pods, deployments, jobs etc.
682 kubectl -n onap get pods | grep -vie 'completed' -e 'running'
683 kubectl -n onap get deploy,sts,jobs
689 After completing the first part above, we should have a functional ONAP deployment for the Jakarta Release.
691 We will need to apply a few modifications to the deployed ONAP Jakarta instance in order to run the use case.
693 Retrieving logins and passwords of ONAP components
694 ++++++++++++++++++++++++++++++++++++++++++++++++++
696 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.
700 kubectl get secret `kubectl get secrets | grep mariadb-galera-db-root-password | awk '{print $1}'` -o jsonpath="{.data.login}" | base64 --decode
701 kubectl get secret `kubectl get secrets | grep mariadb-galera-db-root-password | awk '{print $1}'` -o jsonpath="{.data.password}" | base64 --decode
703 In this case login is empty as the secret is dedicated to root user.
706 Postman collection setup
707 ++++++++++++++++++++++++
709 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.
711 Postman collection is used also to trigger instantiation using SO APIs.
713 Following steps are needed to setup Postman:
715 - Import this Postman collection zip
717 :download:`Postman collection <files/vFW_CNF_CDS/postman.zip>`
719 - 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.
720 - `vFW_CNF_CDS.postman_collection.json`
721 - `vFW_CNF_CDS.postman_environment.json`
723 - 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.
727 kubectl -n onap edit svc so-catalog-db-adapter
728 - .spec.type: ClusterIP
729 + .spec.type: NodePort
730 + .spec.ports[0].nodePort: 30120
732 .. note:: The port number 30120 is used in included Postman collection
734 - 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:
738 kubectl edit -n onap svc cds-blueprints-processor-http
739 - .spec.type: ClusterIP
740 + .spec.type: NodePort
741 + .spec.ports[0].nodePort: 30499
743 .. note:: The port number 30499 is used in included Postman collection
745 **Postman variables:**
747 Most of the Postman variables are automated by Postman scripts and environment file provided, but there are few mandatory variables to fill by user.
749 ===================== ===================
751 --------------------- -------------------
752 k8s ONAP Kubernetes host
753 sdnc_port port of sdnc service for accessing MDSAL
754 service-name name of service as defined in SDC
755 service-version version of service defined in SDC (if service wasn't updated, it should be set to "1.0")
756 service-instance-name name of instantiated service (if ending with -{num}, will be autoincremented for each instantiation request)
757 ===================== ===================
759 You can get the sdnc_port value with
763 kubectl -n onap get svc sdnc -o json | jq '.spec.ports[]|select(.port==8282).nodePort'
765 Automation Environment Setup
766 ............................
768 Whole content of this use case is stored into single git repository and it contains both the required onboarding information as well as automation scripts for onboarding and instantiation of the use case.
772 git clone --single-branch --branch jakarta "https://gerrit.onap.org/r/demo"
773 cd demo/heat/vFW_CNF_CDS/templates
775 In order to prepare environment for onboarding and instantiation of the use case make sure you have *git*, *make*, *helm* and *pipenv* applications installed.
777 The automation scripts are based on `Python SDK`_ and are adopted to automate process of service onboarding, instantiation, deletion and cloud region registration. To configure them for further use:
781 cd demo/heat/vFW_CNF_CDS/automation
783 1. Install required packages with
786 pipenv pipenv install
788 2. Run virtual python environment
793 3. Add kubeconfig files, one for ONAP cluster, and one for k8s cluster that will host vFW
795 .. note:: Both files can be configured after creation of k8s cluster for vFW instance `2-1 Installation of Managed Kubernetes`_. Make sure that they have configured external IP address properly. If any cluster uses self signed certificates set also *insecure-skip-tls-verify* flag in the config file.
797 - artifacts/cluster_kubeconfig - IP address must be reachable by ONAP pods, especially *mutlicloud-k8s* pod
799 - artifacts/onap_kubeconfig - IP address must be reachable by automation scripts
801 4. Modify config.py file
803 - SCENARIO - like described in the `The vFW CNF Use Case`_ section
804 - NATIVE - when enabled (default) **Native Helm** path will be used, otherwise **Dummy Heat** path will be used (deprecated)
805 - MACRO_INSTANTIATION - instantiation method used: macro (default) or a'la carte. A'la carte only for the purpose of use with other use cases
806 - K8S_NAMESPACE - k8s namespace to use for deployment of CNF (vfirewall by default)
807 - K8S_VERSION - version of the k8s cluster
808 - K8S_REGION - name of the k8s region from the CLOUD_REGIONS (kud by default)
809 - CLOUD_REGIONS - configuration of k8s or Openstack regions
810 - GLOBAL_CUSTOMER_ID - identifier of customer in ONAP
811 - VENDOR - name of the Vendor in ONAP
812 - SERVICENAME - **Name of your service model in SDC**
813 - SKIP_POST_INSTANTIATION - whether post instantiation configuration should be run (it is set indirectly by *SCENARIO*)
814 - VNF_PARAM_LIST - list of parameters to pass for VNF creation process
815 - VF_MODULE_PARAM_LIST - list of parameters to pass for VF Module creation
817 .. note:: For automation script it is necessary to modify only SCENARIO constant. Other constants may be modified if needed.
822 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.
824 Create all these entries into AAI in this order. Postman collection provided in this demo can be used for creating each entry.
829 Postman -> Initial ONAP setup -> Create
832 - Create Owning-entity
835 - Create Line Of Business
837 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.
841 This step is performed jointly with onboarding step `3-2 Onboarding`_
846 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.
848 This usecase leverages default ONAP naming policy - "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP".
849 To check that the naming policy is created and pushed OK, we can run the command below from inside any ONAP pod.
853 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"
855 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
857 PART 2 - Installation of managed Kubernetes cluster
858 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
860 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.
862 2-1 Installation of Managed Kubernetes
863 ......................................
865 In this demo we use Kubernetes deployment used by ONAP multicloud/k8s team to test their plugin features see `KUD github`_. There's also some outdated instructions in ONAP wiki `KUD in Wiki`_.
867 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.
869 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:
875 Follow instructions in `KUD github`_ and install target Kubernetes cluster in your favorite machine(s), simplest being just one machine. Your cluster nodes(s) needs to be accessible from ONAP Kuberenetes nodes. Make sure your installed *pip* is of **version < 21.0**. Version 21 do not support python 2.7 that is used in *aio.sh* script. Also to avoid performance problems of your k8s cluster make sure you install only necessary plugins and before running *aio.sh* script execute following command
878 export KUD_ADDONS="virtlet ovn4nfv"
880 .. warning:: In order to run vFW CNF Use Case deployment test please make sure that this workaround does not have to be applied as well. `KUD Interface Permission`_
882 2-2 Cloud Registration
883 ......................
885 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.
889 Postman collection have folder/entry for each step. Execute in this order.
892 Postman -> K8s Cloud Region Registration -> Create
895 - Create Cloud Region
896 - Create Complex-Cloud Region Relationship
898 - Create Service Subscription
899 - Create Cloud Tenant
900 - Create Availability Zone
901 - Upload Connectivity Info
903 .. note:: For "Upload Connectivity Info" call you need to provide kubeconfig file of existing KUD cluster. You can find that kubeconfig on deployed KUD in the directory `~/.kube/config` and this file can be easily copied e.g. via SCP. Please ensure that kubeconfig contains external IP of K8s cluster in kubeconfig and correct it, if it's not.
905 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.
907 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
911 kubectl -n onap exec onap-mariadb-galera-0 -it -- mysql -uroot -psecretpassword -D catalogdb
912 select * from cloud_sites;
913 insert into cloud_sites(ID, REGION_ID, IDENTITY_SERVICE_ID, CLOUD_VERSION, CLLI, ORCHESTRATOR) values("k8sregionfour", "k8sregionfour", "DEFAULT_KEYSTONE", "2.5", "clli2", "multicloud");
914 select * from cloud_sites;
917 .. note:: The configuration of the new k8s cloud site is documented also here `K8s cloud site config`_
921 Please copy the kubeconfig file of existing KUD cluster to automation/artifacts/cluster_kubeconfig location `Automation Environment Setup`_ - step **3**. You can find that kubeconfig on deployed KUD in the directory `~/.kube/config` and this file can be easily copied e.g. via SCP. Please ensure that kubeconfig contains external IP of K8s cluster in kubeconfig and correct it, if it's not.
925 python create_cloud_regions.py
927 PART 3 - Execution of the Use Case
928 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
930 This part contains all the steps to run the use case by using ONAP GUIs, Postman or Python automation scripts.
932 3-1 CNF Orchestration Paths in ONAP
933 ...................................
935 Following picture describe the overall sequential flow of the use case for **Native Helm** path (with CNF Adapter)
937 Native Helm CNF Orchestration
938 .............................
940 Introduced in the Guilin release CNF orchestration method brings native distribution of Helm packages from SDC and native orchestration of CNFs (Helm packages) with SO. SO leverages CNF adapter to interact with K8sPlugin that takes resposnibility for the communication with k8s clusters. Heat templates are not required in the SDC onboarding package and, thanks to the fact that SO knows about Helm package orchestration, synchronization of data between k8s clusters and AAI is possible. Only in this path, since Istanbul release, k8s-resource object is created in relation to tenant, vf-module and generic-vnf objects in AAI. SO CNF adapter is resposobile for synchronization of data between AAI and k8s cluster, however currently it happens only once - after creation of CNF by SO, so any further changes (like new pods) will not be synchronized into AAI.
942 .. figure:: files/vFW_CNF_CDS/Native_Helm_Flow.png
945 vFW CNF CDS Use Case sequence flow for *Native Helm* (Guilin+) path.
948 Kubernetes and Helm Compatibility
949 .................................
951 K8sPlugin, in the Istanbul release (0.9.x), supports Helm packages that can be validated by Helm 3.5 application. It means that new Helm fetures introduced after Helm 3.5 version are not supported currently. Moreover, since Jakarta release K8sPlugin 0.10.x implementation supports upgrade operation but CNF Upgrade orchestration workflow is not yet fully supported in SO orchestration workflows. In consequence, new service moel cna e distributed with new Helm package over SDC but the Helm upgrade procedure must be performed by direct call to k8sPlugin. The request payload is almost the same liek for Isnatce create but release-name comes for the already created instance.
955 curl -i -X POST http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/{rb-instance-id}/upgrade
957 K8sPlugin utilizes also v0.19.4 version of K8s client and its compatibility matrix with k8s clusters can be found here `K8s Client Compatibility`_, Compatibility Matrix section.
962 .. note:: Make sure you have performed `Automation Environment Setup`_ steps before following actions here.
964 Creating Onboarding Package
965 +++++++++++++++++++++++++++
967 Content of the onboarding package can be created with provided Makefile in the *template* folder.
969 Complete content of both Onboarding Packages for **Dummy Heat** and **Native Helm** is packaged to the following VSP onboarding package files:
971 - **Dummy Heat** path: **vfw_k8s_demo.zip**
973 - **Native Helm** path: **native_vfw_k8s_demo.zip**
975 .. note:: Procedure requires *make* and *helm* applications installed
979 git clone --single-branch --branch jakarta "https://gerrit.onap.org/r/demo"
980 cd demo/heat/vFW_CNF_CDS/templates
983 The result of make operation execution is following:
987 make[1]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates'
988 rm -rf package_dummy/
989 rm -rf package_native/
991 rm -f vfw_k8s_demo.zip
992 rm -f native_vfw_k8s_demo.zip
993 make[1]: Leaving directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates'
995 make[1]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates'
997 mkdir package_native/
999 make[2]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm'
1000 rm -f base_template-*.tgz
1001 rm -f helm_base_template.tgz
1002 rm -f base_template_cloudtech_k8s_charts.tgz
1003 helm package base_template
1004 Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/base_template-0.2.0.tgz
1005 mv base_template-*.tgz helm_base_template.tgz
1006 cp helm_base_template.tgz base_template_cloudtech_k8s_charts.tgz
1009 rm -f vpkg_cloudtech_k8s_charts.tgz
1011 Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/vpkg-0.2.0.tgz
1012 mv vpkg-*.tgz helm_vpkg.tgz
1013 cp helm_vpkg.tgz vpkg_cloudtech_k8s_charts.tgz
1016 rm -f vfw_cloudtech_k8s_charts.tgz
1018 Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/vfw-0.2.0.tgz
1019 mv vfw-*.tgz helm_vfw.tgz
1020 cp helm_vfw.tgz vfw_cloudtech_k8s_charts.tgz
1023 rm -f vsn_cloudtech_k8s_charts.tgz
1025 Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/vsn-0.2.0.tgz
1026 mv vsn-*.tgz helm_vsn.tgz
1027 cp helm_vsn.tgz vsn_cloudtech_k8s_charts.tgz
1028 make[2]: Leaving directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm'
1029 mv helm/helm_*.tgz package_native/
1030 mv helm/*.tgz package_dummy/
1031 cp base_dummy/* package_dummy/
1032 cp base_native/* package_native/
1034 sed -i 's/"helm_/"/g' cba_dummy/Definitions/vFW_CNF_CDS.json
1035 cd cba_dummy/ && zip -r CBA.zip . -x pom.xml .idea/\* target/\*
1036 adding: Definitions/ (stored 0%)
1037 adding: Definitions/artifact_types.json (deflated 69%)
1038 adding: Definitions/data_types.json (deflated 88%)
1039 adding: Definitions/node_types.json (deflated 90%)
1040 adding: Definitions/policy_types.json (stored 0%)
1041 adding: Definitions/relationship_types.json (stored 0%)
1042 adding: Definitions/resources_definition_types.json (deflated 94%)
1043 adding: Definitions/vFW_CNF_CDS.json (deflated 87%)
1044 adding: Scripts/ (stored 0%)
1045 adding: Scripts/kotlin/ (stored 0%)
1046 adding: Scripts/kotlin/README.md (stored 0%)
1047 adding: Templates/ (stored 0%)
1048 adding: Templates/base_template-mapping.json (deflated 89%)
1049 adding: Templates/base_template-template.vtl (deflated 87%)
1050 adding: Templates/k8s-profiles/ (stored 0%)
1051 adding: Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz (stored 0%)
1052 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ (stored 0%)
1053 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/manifest.yaml (deflated 35%)
1054 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/override_values.yaml (stored 0%)
1055 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json (deflated 51%)
1056 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-template.yaml.vtl (deflated 56%)
1057 adding: Templates/nf-params-mapping.json (deflated 88%)
1058 adding: Templates/nf-params-template.vtl (deflated 44%)
1059 adding: Templates/vfw-mapping.json (deflated 89%)
1060 adding: Templates/vfw-template.vtl (deflated 87%)
1061 adding: Templates/vnf-mapping.json (deflated 89%)
1062 adding: Templates/vnf-template.vtl (deflated 93%)
1063 adding: Templates/vpkg-mapping.json (deflated 89%)
1064 adding: Templates/vpkg-template.vtl (deflated 87%)
1065 adding: Templates/vsn-mapping.json (deflated 89%)
1066 adding: Templates/vsn-template.vtl (deflated 87%)
1067 adding: TOSCA-Metadata/ (stored 0%)
1068 adding: TOSCA-Metadata/TOSCA.meta (deflated 37%)
1069 cd cba/ && zip -r CBA.zip . -x pom.xml .idea/\* target/\*
1070 adding: Definitions/ (stored 0%)
1071 adding: Definitions/artifact_types.json (deflated 69%)
1072 adding: Definitions/data_types.json (deflated 88%)
1073 adding: Definitions/node_types.json (deflated 90%)
1074 adding: Definitions/policy_types.json (stored 0%)
1075 adding: Definitions/relationship_types.json (stored 0%)
1076 adding: Definitions/resources_definition_types.json (deflated 94%)
1077 adding: Definitions/vFW_CNF_CDS.json (deflated 87%)
1078 adding: Scripts/ (stored 0%)
1079 adding: Scripts/kotlin/ (stored 0%)
1080 adding: Scripts/kotlin/README.md (stored 0%)
1081 adding: Templates/ (stored 0%)
1082 adding: Templates/base_template-mapping.json (deflated 89%)
1083 adding: Templates/base_template-template.vtl (deflated 87%)
1084 adding: Templates/k8s-profiles/ (stored 0%)
1085 adding: Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz (stored 0%)
1086 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ (stored 0%)
1087 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/manifest.yaml (deflated 35%)
1088 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/override_values.yaml (stored 0%)
1089 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json (deflated 51%)
1090 adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-template.yaml.vtl (deflated 56%)
1091 adding: Templates/nf-params-mapping.json (deflated 88%)
1092 adding: Templates/nf-params-template.vtl (deflated 44%)
1093 adding: Templates/vfw-mapping.json (deflated 89%)
1094 adding: Templates/vfw-template.vtl (deflated 87%)
1095 adding: Templates/vnf-mapping.json (deflated 89%)
1096 adding: Templates/vnf-template.vtl (deflated 93%)
1097 adding: Templates/vpkg-mapping.json (deflated 89%)
1098 adding: Templates/vpkg-template.vtl (deflated 87%)
1099 adding: Templates/vsn-mapping.json (deflated 89%)
1100 adding: Templates/vsn-template.vtl (deflated 87%)
1101 adding: TOSCA-Metadata/ (stored 0%)
1102 adding: TOSCA-Metadata/TOSCA.meta (deflated 37%)
1103 mv cba/CBA.zip package_native/
1104 mv cba_dummy/CBA.zip package_dummy/
1105 cd package_dummy/ && zip -r vfw_k8s_demo.zip .
1106 adding: base_template.env (deflated 22%)
1107 adding: base_template.yaml (deflated 59%)
1108 adding: base_template_cloudtech_k8s_charts.tgz (stored 0%)
1109 adding: CBA.zip (stored 0%)
1110 adding: MANIFEST.json (deflated 84%)
1111 adding: vfw.env (deflated 23%)
1112 adding: vfw.yaml (deflated 60%)
1113 adding: vfw_cloudtech_k8s_charts.tgz (stored 0%)
1114 adding: vpkg.env (deflated 13%)
1115 adding: vpkg.yaml (deflated 59%)
1116 adding: vpkg_cloudtech_k8s_charts.tgz (stored 0%)
1117 adding: vsn.env (deflated 15%)
1118 adding: vsn.yaml (deflated 59%)
1119 adding: vsn_cloudtech_k8s_charts.tgz (stored 0%)
1120 cd package_native/ && zip -r native_vfw_k8s_demo.zip .
1121 adding: CBA.zip (stored 0%)
1122 adding: helm_base_template.tgz (stored 0%)
1123 adding: helm_vfw.tgz (stored 0%)
1124 adding: helm_vpkg.tgz (stored 0%)
1125 adding: helm_vsn.tgz (stored 0%)
1126 adding: MANIFEST.json (deflated 71%)
1127 mv package_dummy/vfw_k8s_demo.zip .
1128 mv package_native/native_vfw_k8s_demo.zip .
1131 Import this package into SDC and follow onboarding steps.
1133 Service Creation with SDC
1134 +++++++++++++++++++++++++
1138 Service Creation in SDC is composed of the same steps that are performed by most other use-cases. For reference, you can look at `vLB use-case`_
1142 - Remember during VSP onboard to choose "Network Package" Onboarding procedure
1144 Create VF and Service
1145 Service -> Properties Assignment -> Choose VF (at right box):
1147 - sdnc_artifact_name - vnf
1148 - sdnc_model_name - vFW_CNF_CDS
1149 - sdnc_model_version - 8.0.0
1150 - skip_post_instantiation_configuration - True
1152 .. note:: Since Honolulu skip_post_instantiation_configuration flag can be set to *False* if we want to run config-assign/config-deploy operations.
1156 python onboarding.py
1158 Distribution Of Service
1159 +++++++++++++++++++++++
1165 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:
1169 SDC Catalog database should have our service now defined.
1173 Postman -> LCM -> [SDC] Catalog Service
1178 "uuid": "64dd38f3-2307-4e0a-bc98-5c2cbfb260b6",
1179 "invariantUUID": "cd1a5c2d-2d4e-4d62-ac10-a5fe05e32a22",
1180 "name": "vfw_cnf_cds_svc",
1182 "toscaModelURL": "/sdc/v1/catalog/services/64dd38f3-2307-4e0a-bc98-5c2cbfb260b6/toscaModel",
1183 "category": "Network L4+",
1184 "lifecycleState": "CERTIFIED",
1185 "lastUpdaterUserId": "cs0008",
1186 "distributionStatus": "DISTRIBUTED"
1189 Listing should contain entry with our service name **vfw_cnf_cds_svc**.
1191 .. 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.
1195 SO Catalog database should have our service NFs defined now.
1199 Postman -> LCM -> [SO] Catalog DB Service xNFs
1207 "modelName": "VfVfwK8sDemoCnfMc202109231",
1208 "modelUuid": "70edaca8-8c79-468a-aa76-8224cfe686d0",
1209 "modelInvariantUuid": "7901fc89-a94d-434a-8454-1e27b99dc0e2",
1210 "modelVersion": "1.0",
1211 "modelCustomizationUuid": "86dc8af4-aa17-4fc7-9b20-f12160d99718",
1212 "modelInstanceName": "vfw_cnf_cds_vsp 0"
1214 "toscaNodeType": "org.openecomp.resource.vf.VfwCnfCdsVsp",
1218 "nfNamingCode": null,
1219 "multiStageDesign": "false",
1220 "vnfcInstGroupOrder": null,
1221 "resourceInput": "TBD",
1225 "modelName": "VfVfwK8sDemoCnfMc202109231..helm_base_template..module-4",
1226 "modelUuid": "a9f5d65f-20c3-485c-8cf9-eda9ea94300e",
1227 "modelInvariantUuid": "7888f606-3ee8-4edb-b96d-467fead6ee4f",
1228 "modelVersion": "1",
1229 "modelCustomizationUuid": "b9faba47-d03d-4ba1-a117-4c19632b2136"
1232 "vfModuleLabel": "base_template",
1234 "hasVolumeGroup": false
1238 "modelName": "VfVfwK8sDemoCnfMc202109293..helm_vsn..module-1",
1239 "modelUuid": "8e72ed23-4842-471a-ad83-6a4d285c48e1",
1240 "modelInvariantUuid": "4f5a8a02-0dc6-4387-b86e-bd352f711e18",
1241 "modelVersion": "1",
1242 "modelCustomizationUuid": "ab5614d6-25c2-4863-bad3-93e354b4d5ba"
1245 "vfModuleLabel": "vsn",
1247 "hasVolumeGroup": false
1251 "modelName": "VfVfwK8sDemoCnfMc202109293..helm_vpkg..module-2",
1252 "modelUuid": "64f9d622-a8c1-4992-ba35-abdc13f87660",
1253 "modelInvariantUuid": "88d8d71a-30c9-4e00-a6b9-bd86bae7ed37",
1254 "modelVersion": "1",
1255 "modelCustomizationUuid": "37ab4199-19aa-4f63-9a11-d31b8c25ce46"
1258 "vfModuleLabel": "vpkg",
1260 "hasVolumeGroup": false
1264 "modelName": "VfVfwK8sDemoCnfMc202109293..helm_vfw..module-3",
1265 "modelUuid": "f6f62096-d5cc-474e-82c7-655e7d6628b2",
1266 "modelInvariantUuid": "6077ce70-3a1d-47e6-87a0-6aed6a29b089",
1267 "modelVersion": "1",
1268 "modelCustomizationUuid": "879cda5e-7af9-43d2-bd6c-50e330ab328e"
1271 "vfModuleLabel": "vfw",
1273 "hasVolumeGroup": false
1281 .. note:: For **Native Helm** path both modelName will have prefix *helm_* i.e. *helm_vfw* and vfModuleLabel will have *helm_* keyword inside i.e. *VfVfwK8sDemoCnfMc202109293..helm_vfw..module-3*
1285 SDNC should have it's database updated with *sdnc_* properties that were set during service modeling.
1287 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
1292 kubectl -n onap exec onap-mariadb-galera-0 -it -- sh
1293 mysql -uroot -psecretpassword -D sdnctl
1294 MariaDB [sdnctl]> select sdnc_model_name, sdnc_model_version, sdnc_artifact_name from VF_MODEL WHERE customization_uuid = '86dc8af4-aa17-4fc7-9b20-f12160d99718';
1295 +-----------------+--------------------+--------------------+
1296 | sdnc_model_name | sdnc_model_version | sdnc_artifact_name |
1297 +-----------------+--------------------+--------------------+
1298 | vFW_CNF_CDS | 8.0.0 | vnf |
1299 +-----------------+--------------------+--------------------+
1300 1 row in set (0.00 sec)
1303 .. note:: customization_uuid value is the modelCustomizationUuid of the VNF (serviceVnfs response in 2nd Postman call from SO Catalog DB)
1307 CDS should onboard CBA uploaded as part of VF.
1311 Postman -> Distribution Verification -> [CDS] List CBAs
1318 "id": "c505e516-b35d-4181-b1e2-bcba361cfd0a",
1319 "artifactUUId": null,
1320 "artifactType": "SDNC_MODEL",
1321 "artifactVersion": "8.0.0",
1322 "artifactDescription": "Controller Blueprint for vFW_CNF_CDS:8.0.0",
1323 "internalVersion": null,
1324 "createdDate": "2020-05-29T06:02:20.000Z",
1325 "artifactName": "vFW_CNF_CDS",
1327 "updatedBy": "Samuli Silvius <s.silvius@partner.samsung.com>",
1328 "tags": "Samuli Silvius, Lukasz Rajewski, vFW_CNF_CDS"
1333 The list should have the matching entries with SDNC database:
1335 - sdnc_model_name == artifactName
1336 - sdnc_model_version == artifactVersion
1338 You can also use Postman to download CBA for further verification but it's fully optional.
1342 Postman -> Distribution Verification -> [CDS] CBA Download
1346 K8splugin should onboard 4 resource bundles related to helm resources:
1350 Postman -> Distribution Verification -> [K8splugin] List Resource Bundle Definitions
1356 "rb-name": "a9f5d65f-20c3-485c-8cf9-eda9ea94300e",
1357 "rb-version": "b9faba47-d03d-4ba1-a117-4c19632b2136",
1358 "chart-name": "base_template",
1361 "vf_module_model_name": "VfVfwK8sDemoCnfMc202109231..helm_base_template..module-4",
1362 "vf_module_model_uuid": "7888f606-3ee8-4edb-b96d-467fead6ee4f"
1366 "rb-name": "f6f62096-d5cc-474e-82c7-655e7d6628b2",
1367 "rb-version": "879cda5e-7af9-43d2-bd6c-50e330ab328e",
1368 "chart-name": "vfw",
1371 "vf_module_model_name": "VfVfwK8sDemoCnfMc202109293..helm_vfw..module-3",
1372 "vf_module_model_uuid": "6077ce70-3a1d-47e6-87a0-6aed6a29b089"
1376 "rb-name": "8e72ed23-4842-471a-ad83-6a4d285c48e1",
1377 "rb-version": "ab5614d6-25c2-4863-bad3-93e354b4d5ba",
1378 "chart-name": "vsn",
1381 "vf_module_model_name": "VfVfwK8sDemoCnfMc202109293..helm_vsn..module-1",
1382 "vf_module_model_uuid": "4f5a8a02-0dc6-4387-b86e-bd352f711e18"
1386 "rb-name": "64f9d622-a8c1-4992-ba35-abdc13f87660",
1387 "rb-version": "37ab4199-19aa-4f63-9a11-d31b8c25ce46",
1388 "chart-name": "vpkg",
1391 "vf_module_model_name": "VfVfwK8sDemoCnfMc202109293..helm_vpkg..module-2",
1392 "vf_module_model_uuid": "88d8d71a-30c9-4e00-a6b9-bd86bae7ed37"
1399 Distribution is a part of the onboarding step and at this stage is performed
1401 3-3 CNF Instantiation
1402 .....................
1404 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.
1408 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:
1412 Postman -> LCM -> 1.[SDC] Catalog Service
1416 Postman -> LCM -> 2. [SO] Catalog DB Service xNFs
1418 Now actual instantiation can be triggered with:
1422 Postman -> LCM -> 3. [SO] Self-Serve Service Assign & Activate
1426 Required inputs for instantiation process are taken from the *config.py* file.
1429 python instantiation.py
1432 Finally, to follow the progress of instantiation request with SO's GET request:
1438 Postman -> LCM -> 4. [SO] Infra Active Requests
1440 The successful reply payload in that query should start like this:
1445 "requestStatus": "COMPLETE",
1446 "statusMessage": "Macro-Service-createInstance request was executed correctly.",
1447 "flowStatus": "Successfully completed all Building Blocks",
1449 "startTime": 1590996766000,
1450 "endTime": 1590996945000,
1451 "source": "Postman",
1452 "vnfId": "93b3350d-ed6f-413b-9cc5-a158c1676eb0",
1454 "requestBody": "**REDACTED FOR READABILITY**",
1455 "lastModifiedBy": "CamundaBPMN",
1456 "modifyTime": "2020-06-01T07:35:45.000+0000",
1457 "cloudRegion": "k8sregionfour",
1458 "serviceInstanceId": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72",
1459 "serviceInstanceName": "vfw-cnf-16",
1460 "requestScope": "service",
1461 "requestAction": "createInstance",
1462 "requestorId": "11c2ddb7-4659-4bf0-a685-a08dcbb5a099",
1463 "requestUrl": "http://infra:30277/onap/so/infra/serviceInstantiation/v7/serviceInstances",
1464 "tenantName": "k8stenant",
1465 "cloudApiRequests": [],
1466 "requestURI": "6a369c8e-d492-4ab5-a107-46804eeb7873",
1469 "href": "http://infra:30277/infraActiveRequests/6a369c8e-d492-4ab5-a107-46804eeb7873"
1471 "infraActiveRequests": {
1472 "href": "http://infra:30277/infraActiveRequests/6a369c8e-d492-4ab5-a107-46804eeb7873"
1478 Progress can be also followed also with `SO Monitoring`_ dashboard.
1480 Service Instance Termination
1481 ++++++++++++++++++++++++++++
1483 Service instance can be terminated with the following postman call:
1488 Postman -> LCM -> 5. [SO] Service Delete
1495 .. note:: Automated service deletion mecvhanism takes information about the instantiated service instance from the *config.py* file and *SERVICE_INSTANCE_NAME* variable. If you modify this value before the deletion of existing service instance then you will loose opportunity to easy delete already created service instance.
1497 Second Service Instance Instantiation
1498 +++++++++++++++++++++++++++++++++++++
1500 To finally verify that all the work done within this demo, it should be possible to instantiate second vFW instance successfully.
1502 Trigger new instance createion. You can use previous call or a separate one that will utilize profile templating mechanism implemented in CBA:
1507 Postman -> LCM -> 6. [SO] Self-Serve Service Assign & Activate - Second
1511 Before second instance of service is created you need to modify *config.py* file changing the *SERVICENAME* and *SERVICE_INSTANCE_NAME* to different values and by changing the value or *k8s-rb-profile-name* parameter for *vpg* module from value *default* or *vfw-cnf-cds-base-profile* to *vfw-cnf-cds-vpkg-profile* what will result with instantiation of additional ssh service for *vpg* module. Second onboarding in automated case is required due to the existing limitations of *python-sdk* librarier that create vf-module instance name base on the vf-module model name. For manual Postman option vf-module instance name is set on service instance name basis what makes it unique.
1514 python onboarding.py
1515 python instantiation.py
1517 3-4 Results and Logs
1518 ....................
1520 Now multiple instances of Kubernetes variant of vFW are running in target VIM (KUD deployment).
1522 .. figure:: files/vFW_CNF_CDS/vFW_Instance_In_Kubernetes.png
1525 vFW Instance In Kubernetes
1529 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.
1533 Postman -> Instantiation verification**
1535 Execute example Postman queries and check example section to see the valid results.
1537 ========================== =================
1538 Verify Target Postman query
1539 -------------------------- -----------------
1540 Service Instances in AAI **Postman -> Instantiation verification -> [AAI] List Service Instances**
1541 Service Instances in MDSAL **Postman -> Instantiation verification -> [SDNC] GR-API MD-SAL Services**
1542 K8S Instances in KUD **Postman -> Instantiation verification -> [K8splugin] List Instances**
1543 ========================== =================
1545 .. note:: "[AAI] List vServers <Empty>" Request won't return any vserver info from AAI, as currently such information are not provided during instantiation process.
1548 Query also directly from VIM:
1553 ubuntu@kud-host:~$ kubectl get pods,svc,networks,cm,network-attachment-definition,deployments
1554 NAME READY STATUS RESTARTS AGE
1555 pod/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f-7cfb9949d9-8b5vg 1/1 Running 0 22s
1556 pod/vfw-19571429-4af4-49b3-af65-2eb1f97bba43-75cd7c6f76-4gqtz 1/1 Running 0 11m
1557 pod/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-f4485d485-pln8m 1/1 Running 0 11m
1558 pod/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-6f8cff54d-dvw4j 1/1 Running 0 32s
1559 pod/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-5879c56fd-q59l7 2/2 Running 0 11m
1560 pod/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-5889b7455-96j9d 2/2 Running 0 30s
1562 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
1563 service/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-management-api NodePort 10.244.43.245 <none> 2831:30831/TCP 11m
1564 service/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-management-api NodePort 10.244.1.45 <none> 2831:31831/TCP 33s
1565 service/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-darkstat-ui NodePort 10.244.16.187 <none> 667:30667/TCP 11m
1566 service/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-darkstat-ui NodePort 10.244.20.229 <none> 667:31667/TCP 30s
1569 network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-management-network 40s
1570 network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-protected-network 40s
1571 network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-unprotected-network 40s
1572 network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-management-network 11m
1573 network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-protected-network 11m
1574 network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-unprotected-network 11m
1577 configmap/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f-configmap 6 22s
1578 configmap/vfw-19571429-4af4-49b3-af65-2eb1f97bba43-configmap 6 11m
1579 configmap/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-configmap 6 11m
1580 configmap/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-configmap 6 33s
1581 configmap/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-configmap 2 11m
1582 configmap/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-configmap 2 30s
1585 networkattachmentdefinition.k8s.cni.cncf.io/55118b80-8470-4c99-bfdf-d122cd412739-ovn-nat 40s
1586 networkattachmentdefinition.k8s.cni.cncf.io/567cecc3-9692-449e-877a-ff0b560736be-ovn-nat 11m
1588 NAME READY UP-TO-DATE AVAILABLE AGE
1589 deployment.extensions/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f 1/1 1 1 22s
1590 deployment.extensions/vfw-19571429-4af4-49b3-af65-2eb1f97bba43 1/1 1 1 11m
1591 deployment.extensions/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e 1/1 1 1 11m
1592 deployment.extensions/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26 1/1 1 1 33s
1593 deployment.extensions/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14 1/1 1 1 11m
1594 deployment.extensions/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b 1/1 1 1 30s
1597 Component Logs From The Execution
1598 +++++++++++++++++++++++++++++++++
1602 All logs from the use case execution can be retrieved with following
1606 kubectl -n onap logs `kubectl -n onap get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep -m1 <COMPONENT_NAME>` -c <CONTAINER>
1608 where <COMPONENT_NAME> and <CONTAINER> should be replaced with following keywords respectively:
1610 - so-bpmn-infra, so-bpmn-infra
1611 - so-openstack-adapter, so-openstack-adapter
1612 - so-cnf-adapter, so-cnf-adapter
1615 From karaf.log all requests (payloads) to CDS can be found by searching following string:
1617 ``'Sending request below to url http://cds-blueprints-processor-http:8080/api/v1/execution-service/process'``
1619 - cds-blueprints-processor, cds-blueprints-processor
1620 - multicloud-k8s, multicloud-k8s
1621 - network-name-gen, network-name-gen,
1625 In case more detailed logging is needed, here's instructions how to setup DEBUG logging for few components.
1631 kubectl -n onap exec -it onap-sdnc-0 -c sdnc /opt/opendaylight/bin/client log:set DEBUG
1634 - CDS Blueprint Processor
1639 kubectl -n onap edit configmap onap-cds-blueprints-processor-configmap
1641 # Edit logback.xml content change root logger level from info to debug.
1642 <root level="debug">
1643 <appender-ref ref="STDOUT"/>
1646 # Delete the Pods to make changes effective
1647 kubectl -n onap delete pods -l app=cds-blueprints-processor
1649 3-5 Verification of the CNF Status
1650 ..................................
1654 The Guilin introduced new API for verification of the status of instantiated resources in k8s cluster. The API gives result similar to *kubectl describe* operation for all the resources created for particular *rb-definition*. Status API can be used to verify the k8s resources after instantiation but also can be used leveraged for synchronization of the information with external components, like AAI. To use Status API call
1658 curl -i http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/{rb-instance-id}/status
1660 where {rb-instance-id} can be taken from the list of instances resolved the following call or from AAI *heat-stack-id* property of created *vf-module* associated with each Helm package from onboarded VSP which holds the *rb-instance-id* value.
1662 The same API can be accessed over cnf-adapter endpoint (ClusterIP):
1666 curl -i http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/{rb-instance-id}/status
1668 The similar to Status API is Query API, avaialble since Honolulu, that allows to fetch specific resources that belong to the created instance. The Query API allows to filter resources by Name, Kind, APiVersion, Namespace and Labels. The k8splugin endpoint is:
1672 curl -i http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/{rb-instance-id}/query?ApiVersion=v1&Kind=Deployment&Name=vfw-1-vfw&Namespace=vfirewall
1674 and cnf-adapter endpoint is:
1678 curl -i http://${K8S_NODE_IP}:8090/api/cnf-adapter/v1/instance/{rb-instance-id}/query?ApiVersion=v1&Kind=Deployment&Name=vfw-1-vfw&Namespace=vfirewall
1681 Examplary output of Status API is shown below (full result of test vFW CNF helm package in the attached file). It shows the list of GVK resources created for requested *rb-instance* (Helm and vf-module in the same time) with assocated describe result for all of them.
1683 :download:`Full Status API Result <files/vFW_CNF_CDS/status-response.json>`
1690 "rb-version": "plugin_test",
1691 "profile-name": "test_profile",
1693 "cloud-region": "kud",
1695 "testCaseName": "plugin_fw.sh"
1697 "override-values": {
1698 "global.onapPrivateNetworkName": "onap-private-net-test"
1703 "resourcesStatus": [
1705 "name": "sink-configmap",
1714 "protected_net_gw": "192.168.20.100",
1715 "protected_private_net_cidr": "192.168.10.0/24"
1717 "kind": "ConfigMap",
1719 "creationTimestamp": "2020-09-29T13:36:25Z",
1721 "k8splugin.io/rb-instance-id": "practical_nobel"
1723 "name": "sink-configmap",
1724 "namespace": "plugin-tests-namespace",
1725 "resourceVersion": "10720771",
1726 "selfLink": "/api/v1/namespaces/plugin-tests-namespace/configmaps/sink-configmap",
1727 "uid": "46c8bec4-980c-455b-9eb0-fb84ac8cc450"
1736 Since Honolulu release vFW CNF Use Case is equipped with dedicated mechanisms for verification of the CNF status automatically, during the instantiation. The process utilizes the k8sPlugin Status and Healthcheck APIs that both are natively exposed in the CDS and can be executed from the script execution functionality in the CDS.
1738 .. figure:: files/vFW_CNF_CDS/healthcheck.png
1742 vFW CNF Healthcheck flow concept
1744 There is exposed a dedicated workflow in CBA, where Status API result verification is run with *status-verification-script* step and execution of the healthcheck job is run with *health-check-process*. The first one verifies if all pods have *Running* state. If yes, then verification of the health is started by execution of the dedicated Helm tests which are a jobs that verify connectivity in each component.
1751 "description": "Gather necessary input for config init and status verification",
1752 "target": "config-setup-process",
1755 "call_operation": "ResourceResolutionComponent.process"
1765 "status-verification-script": {
1766 "description": "Simple status verification script",
1767 "target": "simple-status-check",
1770 "call_operation": "ComponentScriptExecutor.process"
1774 "health-check-process"
1780 "health-check-process": {
1781 "description": "Start health check script",
1782 "target": "health-check-script",
1785 "call_operation": "ComponentScriptExecutor.process"
1796 "description": "Simple error verification script",
1797 "target": "simple-error-check",
1800 "call_operation": "ComponentScriptExecutor.process"
1807 "collect-results": {
1808 "description": "Final collection of results",
1809 "target": "collect-results"
1814 Since Istanbul release, SO is equipped with dedicated workflow for verification of the CNF status. It works similarly to the workflow introduced in Honolulu, however basic CNF Status Verification step utilizes "Ready" flag of the StatusAPI response to check if k8s resources created from Helm package are up and running. Ready flag works properly in k8splugin 0.9.1 or higher. Both operations are performed by ControllerExecutionBB in SO and are realized by cnf-adapter component in SO. This workflow can be triggered by a dedicated endpoint documented here: `CNF Health Check`_. This workflow is not yet integrated into automation scripts.
1816 3-6 Synchronization of created k8s resources into AAI
1817 .....................................................
1819 Since Istanbul release `AAI v24 schema`_ version is used to store basic information about k8s resources deployed from each helm package. The AAI change is described in `K8s Resource in AAI`_. The information stored in AAI lets to identify all the deployed k8s resoureces but the details about them have to be fetched from the k8s cluster on demand. Such design is motivated by high frequency of k8s resource status change and the plethora of resource types avaialble in k8s - including the CRDs that extend the predefined resource types available in k8s. In consequence, there was no sense to store in AAI full runtime picture of the k8s resources as the synchronization of them would be impossible.
1821 K8s-Resource object is stored in the cloud-infrastructure set of AAI APIs and it belongs to the tenant, and is related with both generic-vnf and vf-module. Each k8s-resource object created in AAI has selflink for cnf-adapter Query API, described in `3-5 Verification of the CNF Status`_, that allows to fetch actual information about the resource in k8s. The examplary set of k8s-resources with related generic-vnf and vf-modules for vFW CNF use case is in the files attached below.
1823 :download:`List of K8s Resources <files/vFW_CNF_CDS/k8s-resources-response.json>`
1825 :download:`Generic VNF with modules <files/vFW_CNF_CDS/vfw-generic-vnf-aai.json>`
1827 :download:`vPKG VF-Module with related k8s-resource relations <files/vFW_CNF_CDS/vpkg-vf-module-aai.json>`
1829 AAI synchronization is run just after creation of the vf-module by SO. Since Jakarta release, cnf-adapter synchronizes into AAI information about any change on k8s resources performed after their initial creation. For instance, if pod is deleted in k8s cluster, the new one is automatically created. In consequence, K8sPlugin sends notification about the change to cnf-adapter, and the latter one performs update of the information in AAI by removing the old pod and creating the new one in AAI. The update in AAI, after the change in k8s cluster, should by applied with no more than 30s delay.
1831 In order to force an imidiate update of AAI information about the concrete Helm package, the following API can be also used with properly modified body (all except the callbackUrl).
1835 curl -i -X POST http://${K8S_NODE_IP}:8090/api/cnf-adapter/v1/aai-update
1841 "instanceId": "keen_darwin",
1842 "cloudRegion": "kud",
1843 "cloudOwner": "K8sCloudOwner",
1844 "tenantId": "dca807fa-0d3e-4fb1-85eb-b9e1c03108a3",
1845 "callbackUrl": "http://example",
1846 "genericVnfId": "8b3af2e0-fd66-460d-b928-22f5dac517a6",
1847 "vfModuleId": "a0161551-9d13-47c2-ba4f-896d4ee401d4"
1851 PART 4 - Future improvements needed
1852 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1854 Future development areas for this use case:
1856 - Include Closed Loop part of the vFW CNF demo.
1857 - vFW service with Openstack VNF (KUD) and Kubernetes CNF
1859 Future development areas for CNF support:
1861 - Extraction of override values in time of the package onboarding
1862 - Upgrade of the vFW CNF similar to Helm Upgrade through the SDC and SO
1863 - Use multicloud/k8S API v2 (EMCO)
1865 Some of the features from the list above are covered by the Jakarta roadmap described in `REQ-890`_.
1868 .. _ONAP Deployment Guide: https://docs.onap.org/projects/onap-oom/en/latest/sections/guides/deployment_guides/oom_deployment.html
1869 .. _CDS Documentation: https://docs.onap.org/projects/onap-ccsdk-cds/en/latest/
1870 .. _vLB use-case: https://wiki.onap.org/pages/viewpage.action?pageId=71838898
1871 .. _vFW_CNF_CDS Model: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates?h=guilin
1872 .. _vFW_CNF_CDS Automation: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/automation?h=guilin
1873 .. _vFW CDS Dublin: https://wiki.onap.org/display/DW/vFW+CDS+Dublin
1874 .. _vFW CBA Model: https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/service-blueprint/vFW?h=elalto
1875 .. _vFW_Helm Model: https://git.onap.org/multicloud/k8s/tree/kud/demo/firewall?h=elalto
1876 .. _vFW_NextGen: https://git.onap.org/demo/tree/heat/vFW_NextGen?h=elalto
1877 .. _vFW EDGEX K8S: https://docs.onap.org/projects/onap-integration/en/latest/docs_vfw_edgex_k8s.html
1878 .. _vFW EDGEX K8S In ONAP Wiki: https://wiki.onap.org/display/DW/Deploying+vFw+and+EdgeXFoundry+Services+on+Kubernets+Cluster+with+ONAP
1879 .. _KUD github: https://github.com/onap/multicloud-k8s/tree/honolulu/kud/hosting_providers/baremetal
1880 .. _KUD in Wiki: https://wiki.onap.org/display/DW/Kubernetes+Baremetal+deployment+setup+instructions
1881 .. _Multicloud k8s gerrit: https://gerrit.onap.org/r/q/status:open+project:+multicloud/k8s
1882 .. _KUD subproject in github: https://github.com/onap/multicloud-k8s/tree/honolulu/kud
1883 .. _KUD Interface Permission: https://jira.onap.org/browse/MULTICLOUD-1310
1884 .. _Frankfurt CBA Definition: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba/Definitions/vFW_CNF_CDS.json?h=frankfurt
1885 .. _Frankfurt CBA Script: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba/Scripts/kotlin/KotlinK8sProfileUpload.kt?h=frankfurt
1886 .. _SO-3403: https://jira.onap.org/browse/SO-3403
1887 .. _SO-3404: https://jira.onap.org/browse/SO-3404
1888 .. _REQ-182: https://jira.onap.org/browse/REQ-182
1889 .. _REQ-341: https://jira.onap.org/browse/REQ-341
1890 .. _REQ-458: https://jira.onap.org/browse/REQ-458
1891 .. _REQ-627: https://jira.onap.org/browse/REQ-627
1892 .. _REQ-890: https://jira.onap.org/browse/REQ-890
1893 .. _Python SDK: https://docs.onap.org/projects/onap-integration/en/latest/integration-tooling.html#python-onap-sdk
1894 .. _KUD Jenkins ci/cd verification: https://jenkins.onap.org/job/multicloud-k8s-master-kud-deployment-verify-shell/
1895 .. _K8s cloud site config: https://docs.onap.org/en/latest/guides/onap-operator/cloud_site/k8s/index.html
1896 .. _SO Monitoring: https://docs.onap.org/projects/onap-so/en/latest/developer_info/Working_with_so_monitoring.html
1897 .. _Data Dictionary: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba-dd.json?h=guilin
1898 .. _Helm Healer: https://git.onap.org/oom/offline-installer/tree/tools/helm-healer.sh?h=frankfurt
1899 .. _infra_workload: https://docs.onap.org/projects/onap-multicloud-framework/en/latest/specs/multicloud_infra_workload.html?highlight=multicloud
1900 .. _K8s Client Compatibility: https://github.com/kubernetes/client-go
1901 .. _CNF Health Check: https://docs.onap.org/projects/onap-so/en/latest/api/apis/serviceInstances-api.html#healthcheck
1902 .. _K8s Resource in AAI: https://jira.onap.org/browse/ONAPMODEL-37
1903 .. _AAI v24 schema: https://nexus.onap.org/service/local/repositories/releases/archive/org/onap/aai/schema-service/aai-schema/1.9.2/aai-schema-1.9.2.jar/!/onap/aai_swagger_html/aai_swagger_v24.html