docs/docs_vFW_CNF_CDS.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3 .. Copyright 2021 ONAP
   4
   5 .. _docs_vFW_CNF_CDS:
   6
   7 :orphan:
   8
   9 vFirewall CNF Use Case
  10 ----------------------
  11
  12 Source files
  13 ~~~~~~~~~~~~
  14 - Heat/Helm/CDS models: `vFW_CNF_CDS Model`_
  15 - Automation Scripts: `vFW_CNF_CDS Automation`_
  16
  17 Description
  18 ~~~~~~~~~~~
  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`_.
  20
  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:
  22
  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.
  35
  36 All changes to related ONAP components and Use Case can be found in the following tickets:
  37
  38 - `REQ-182`_
  39 - `REQ-341`_
  40 - `REQ-458`_
  41 - `REQ-627`_
  42
  43 **Since Guilin ONAP supports Helm packages as a native onboarding artifacts and SO natively orchestrates Helm packages what brings significant advantages in the future. Also since Guilin release ONAP has first mechanisms for monitoring of the status of deployed CNF resources. Since Honolulu release native CNF testing capability was enabled that allows for execution of the dedicated test jobs for each helm package**.
  44
  45 The vFW CNF Use Case
  46 ~~~~~~~~~~~~~~~~~~~~
  47 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
  49 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
  51 Demo git directory has also `Data Dictionary`_ file (CDS model time resource) included.
  52
  53 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
  55 Following table describes all the source models to which this demo is based on.
  56
  57 ===============  =================       ===========
  58 Model            Git reference           Description
  59 ---------------  -----------------       -----------
  60 Heat             `vFW_NextGen`_          Heat templates used in original vFW demo but split into multiple vf-modules
  61 Helm             `vFW_Helm Model`_       Helm templates used in `vFW EDGEX K8S`_ demo
  62 CDS model        `vFW CBA Model`_        CDS CBA model used in `vFW CDS Dublin`_ demo
  63 ===============  =================       ===========
  64
  65 .. 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
  67 Since Honolulu release vFW CNF use case supports three different scenarios where different capabilities of CNF Orchestration in ONAP can be experimented:
  68
  69 .. figure:: files/vFW_CNF_CDS/scenarios.png
  70    :scale: 60 %
  71    :align: center
  72
  73    vFW CNF Scenarios
  74
  75 - Scenario 1: simple deployment of vFW CNF instance
  76 - Scenario 2: deployment of vFW CNF instance with enrichment of the Helm deployment with profiling mechanism
  77 - Scenario 3: deployment of vFW CNF instance with Day2 configuration applied and CNF status checked as a part of a config-deploy operation
  78
  79 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
  81 Modeling of Onboarding Package/Helm
  82 ...................................
  83
  84 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
  86 The Istanbul version of the `vFW_CNF_CDS Model`_ contains files required to create **VSP onboarding packages in two formats**: the **Dummy Heat** (available in Frankfurt release already) one that considers association of each Helm package with dummy heat templates and the **Native Helm** one where each Helm package is standalone and is natively understood in consequence by SO. For both variants of VSP Helm packages are matched to the vf-module concept, so basically each Helm application after instantiation is visible to ONAP as a separate vf-module. The chosen format for onboarding has **crucial** role in the further orchestration approach applied for Helm package instantiation. The **Dummy Heat** will result with orchestration through the **Openstack Adapter** component of SO while **Native Helm** will result with **CNF Adapter**. Both approaches will result with instantiation of the same CNF, however the **Native Helm** approach will be enhanced in the future releases while **Dummy Heat** approach will become deprecated in the future. Read more in `3-1 CNF Orchestration Paths in ONAP`_
  87
  88 Produced **Dummy Heat** VSP onboarding package `Creating Onboarding Package`_ format has following MANIFEST file (package_dummy/MANIFEST.json). The Helm package is delivered as CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT package through SDC and SO. Dummy heat templates are matched to Helm packages by the same prefix <vf_module_label> of the file name that for both dummy Heat template and for CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT must be the same, like i.e. *vpg* vf-module in the manifest file below. The name of the CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT artifact is predefined and needs to match the pattern: <vf_module_label>_cloudtech_k8s_charts.tgz.
  89
  90 ::
  91
  92     {
  93         "name": "virtualFirewall",
  94         "description": "",
  95         "data": [
  96             {
  97                 "file": "CBA.zip",
  98                 "type": "CONTROLLER_BLUEPRINT_ARCHIVE"
  99             },
 100             {
 101                 "file": "base_template.yaml",
 102                 "type": "HEAT",
 103                 "isBase": "true",
 104                 "data": [
 105                     {
 106                         "file": "base_template.env",
 107                         "type": "HEAT_ENV"
 108                     }
 109                 ]
 110             },
 111             {
 112                 "file": "base_template_cloudtech_k8s_charts.tgz",
 113                 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
 114             },
 115             {
 116                 "file": "vfw.yaml",
 117                 "type": "HEAT",
 118                 "isBase": "false",
 119                 "data": [
 120                     {
 121                         "file": "vfw.env",
 122                         "type": "HEAT_ENV"
 123                     }
 124                 ]
 125             },
 126             {
 127                 "file": "vfw_cloudtech_k8s_charts.tgz",
 128                 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
 129             },
 130             {
 131                 "file": "vpkg.yaml",
 132                 "type": "HEAT",
 133                 "isBase": "false",
 134                 "data": [
 135                     {
 136                         "file": "vpkg.env",
 137                         "type": "HEAT_ENV"
 138                     }
 139                 ]
 140             },
 141             {
 142                 "file": "vpkg_cloudtech_k8s_charts.tgz",
 143                 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
 144             },
 145             {
 146                 "file": "vsn.yaml",
 147                 "type": "HEAT",
 148                 "isBase": "false",
 149                 "data": [
 150                     {
 151                         "file": "vsn.env",
 152                         "type": "HEAT_ENV"
 153                     }
 154                 ]
 155             },
 156             {
 157                 "file": "vsn_cloudtech_k8s_charts.tgz",
 158                 "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT"
 159             }
 160         ]
 161     }
 162
 163 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.
 164
 165 ::
 166
 167     {
 168         "name": "virtualFirewall",
 169         "description": "",
 170         "data": [
 171             {
 172                 "file": "CBA.zip",
 173                 "type": "CONTROLLER_BLUEPRINT_ARCHIVE"
 174             },
 175             {
 176                 "file": "helm_base_template.tgz",
 177                 "type": "HELM",
 178                 "isBase": "true"
 179             },
 180             {
 181                 "file": "helm_vfw.tgz",
 182                 "type": "HELM",
 183                 "isBase": "false"
 184             },
 185             {
 186                 "file": "helm_vpkg.tgz",
 187                 "type": "HELM",
 188                 "isBase": "false"
 189             },
 190             {
 191                 "file": "helm_vsn.tgz",
 192                 "type": "HELM",
 193                 "isBase": "false"
 194             }
 195         ]
 196     }
 197
 198 .. 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.
 199
 200 CDS Model (CBA)
 201 ...............
 202
 203 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.
 204
 205 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`_.
 206
 207 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.
 208
 209 Base on this example there are demonstrated following features of CDS and CBA model
 210
 211 - resource assignment string, integer and json types
 212 - sourcing of resolved value on vf-module level from vnf level assignment
 213 - extracting data from AAI and MD-SAL during the resource assignment
 214 - custom resource assignment with Kotlin script
 215 - templating of the vtl files
 216 - building of imperative workflows
 217 - utilization of on_succes and on_failure event in imperative workflow
 218 - handling of the failure in the workflow
 219 - implementation of custom workflow logic with Kotlin script
 220 - example of config-assign and config-deploy operation decomposed into many steps
 221 - complex parametrization of config deploy operation
 222 - combination and aggregation of AAI and MD-SAL data in config-assign and config-deploy operations
 223
 224 The prepared CBA model demonstrates also how to utilize CNF specific features of CBA, suited for the deployment of CNF with k8splugin in ONAP:
 225
 226 - building and upload of k8s profile template into k8splugin
 227 - building and upload of k8s configuration template into k8splugin
 228 - parametrization and creation of configuration instance from configuration template
 229 - validation of CNF status with Kotlin script
 230
 231 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 list of artifact with the templates is different for **Dummy Heat** and **Native Helm** approach. The second one has artifact names starting with *helm_* prefix, in the same way like names of artifacts in the MANIFEST file of VSP differs. The **Dummy Heat** artifacts' list is following:
 232
 233 ::
 234
 235     "artifacts" : {
 236       "base_template-template" : {
 237         "type" : "artifact-template-velocity",
 238         "file" : "Templates/base_template-template.vtl"
 239       },
 240       "base_template-mapping" : {
 241         "type" : "artifact-mapping-resource",
 242         "file" : "Templates/base_template-mapping.json"
 243       },
 244       "vpkg-template" : {
 245         "type" : "artifact-template-velocity",
 246         "file" : "Templates/vpkg-template.vtl"
 247       },
 248       "vpkg-mapping" : {
 249         "type" : "artifact-mapping-resource",
 250         "file" : "Templates/vpkg-mapping.json"
 251       },
 252       "vfw-template" : {
 253         "type" : "artifact-template-velocity",
 254         "file" : "Templates/vfw-template.vtl"
 255       },
 256       "vfw-mapping" : {
 257         "type" : "artifact-mapping-resource",
 258         "file" : "Templates/vfw-mapping.json"
 259       },
 260       "vnf-template" : {
 261         "type" : "artifact-template-velocity",
 262         "file" : "Templates/vnf-template.vtl"
 263       },
 264       "vnf-mapping" : {
 265         "type" : "artifact-mapping-resource",
 266         "file" : "Templates/vnf-mapping.json"
 267       },
 268       "vsn-template" : {
 269         "type" : "artifact-template-velocity",
 270         "file" : "Templates/vsn-template.vtl"
 271       },
 272       "vsn-mapping" : {
 273         "type" : "artifact-mapping-resource",
 274         "file" : "Templates/vsn-mapping.json"
 275       }
 276     }
 277
 278 The **Native Helm** artifacts' list is following:
 279
 280 ::
 281
 282     "artifacts" : {
 283       "helm_base_template-template" : {
 284         "type" : "artifact-template-velocity",
 285         "file" : "Templates/base_template-template.vtl"
 286       },
 287       "helm_base_template-mapping" : {
 288         "type" : "artifact-mapping-resource",
 289         "file" : "Templates/base_template-mapping.json"
 290       },
 291       "helm_vpkg-template" : {
 292         "type" : "artifact-template-velocity",
 293         "file" : "Templates/vpkg-template.vtl"
 294       },
 295       "helm_vpkg-mapping" : {
 296         "type" : "artifact-mapping-resource",
 297         "file" : "Templates/vpkg-mapping.json"
 298       },
 299       "helm_vfw-template" : {
 300         "type" : "artifact-template-velocity",
 301         "file" : "Templates/vfw-template.vtl"
 302       },
 303       "helm_vfw-mapping" : {
 304         "type" : "artifact-mapping-resource",
 305         "file" : "Templates/vfw-mapping.json"
 306       },
 307       "vnf-template" : {
 308         "type" : "artifact-template-velocity",
 309         "file" : "Templates/vnf-template.vtl"
 310       },
 311       "vnf-mapping" : {
 312         "type" : "artifact-mapping-resource",
 313         "file" : "Templates/vnf-mapping.json"
 314       },
 315       "helm_vsn-template" : {
 316         "type" : "artifact-template-velocity",
 317         "file" : "Templates/vsn-template.vtl"
 318       },
 319       "helm_vsn-mapping" : {
 320         "type" : "artifact-mapping-resource",
 321         "file" : "Templates/vsn-mapping.json"
 322       }
 323     }
 324
 325 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.
 326
 327 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.
 328
 329 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.
 330
 331 ::
 332
 333   ---
 334   version: v1
 335   type:
 336     values: "override_values.yaml"
 337     configresource:
 338       - filepath: resources/deployment.yaml
 339         chartpath: templates/deployment.yaml
 340
 341
 342 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.
 343
 344 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.
 345
 346 ::
 347
 348     "resource-assignment": {
 349         "steps": {
 350             "resource-assignment": {
 351                 "description": "Resource Assign Workflow",
 352                 "target": "resource-assignment",
 353                 "activities": [
 354                     {
 355                         "call_operation": "ResourceResolutionComponent.process"
 356                     }
 357                 ],
 358                 "on_success": [
 359                     "profile-upload"
 360                 ]
 361             },
 362             "profile-upload": {
 363                 "description": "Generate and upload K8s Profile",
 364                 "target": "k8s-profile-upload",
 365                 "activities": [
 366                     {
 367                         "call_operation": "ComponentScriptExecutor.process"
 368                     }
 369                 ]
 370             }
 371         },
 372
 373 .. 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.
 374
 375 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*).
 376
 377 ::
 378
 379     {
 380         "name": "vpg-management-port",
 381         "property": {
 382             "description": "The number of node port for ssh service of vpg",
 383             "type": "integer",
 384             "default": "0"
 385         },
 386         "input-param": false,
 387         "dictionary-name": "vpg-management-port",
 388         "dictionary-source": "default",
 389         "dependencies": []
 390     }
 391
 392 *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.
 393
 394 ::
 395
 396   apiVersion: v1
 397   kind: Service
 398   metadata:
 399     name: {{ .Values.vpg_name_0 }}-ssh-access
 400     labels:
 401       vnf-name: {{ .Values.vnf_name }}
 402       vf-module-name: {{ .Values.vpg_name_0 }}
 403       release: {{ .Release.Name }}
 404       chart: {{ .Chart.Name }}
 405   spec:
 406     type: NodePort
 407     ports:
 408       - port: 22
 409         nodePort: ${vpg-management-port}
 410     selector:
 411       vf-module-name: {{ .Values.vpg_name_0 }}
 412       release: {{ .Release.Name }}
 413       chart: {{ .Chart.Name }}
 414
 415 .. 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).
 416
 417 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.
 418
 419 ::
 420
 421     "k8s-profile-upload": {
 422         "type": "component-k8s-profile-upload",
 423         "interfaces": {
 424             "K8sProfileUploadComponent": {
 425                 "operations": {
 426                     "process": {
 427                         "inputs": {
 428                             "artifact-prefix-names": {
 429                                 "get_input": "template-prefix"
 430                             },
 431                             "resource-assignment-map": {
 432                                 "get_attribute": [
 433                                     "resource-assignment",
 434                                     "assignment-map"
 435                                 ]
 436                             }
 437                         }
 438                     }
 439                 }
 440             }
 441         },
 442         "artifacts": {
 443             "vfw-cnf-cds-base-profile": {
 444                 "type": "artifact-k8sprofile-content",
 445                 "file": "Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz"
 446             },
 447             "vfw-cnf-cds-vpkg-profile": {
 448                 "type": "artifact-k8sprofile-content",
 449                 "file": "Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile"
 450             },
 451             "vfw-cnf-cds-vpkg-profile-mapping": {
 452                 "type": "artifact-mapping-resource",
 453                 "file": "Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json"
 454             }
 455         }
 456     }
 457
 458 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.
 459
 460 .. figure:: files/vFW_CNF_CDS/profile-templating.png
 461    :align: center
 462
 463    K8s Profile Templating
 464
 465 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:
 466
 467 - k8s-rb-definition-name - the name under which RB definition was created - **VF Module Model Invariant ID** in ONAP
 468 - k8s-rb-definition-version - the version of created RB definition name - **VF Module Model Customization ID**  in ONAP
 469 - k8s-rb-profile-name - (mandatory) the name of the profile under which it will be created in k8s plugin. Other parameters are required only when profile must be uploaded because it does not exist yet
 470 - k8s-rb-profile-source - the source of profile content - name of the artifact of the profile. If missing *k8s-rb-profile-name* is treated as a source
 471 - k8s-rb-profile-namespace - the k8s namespace name associated with profile being created
 472 - k8s-rb-profile-kubernetes-version - 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.
 473 - resource-assignment-map - result of the associated resource assignment step - it may deliver values of inputs if they are not specified directly
 474 - artifact-prefix-names - (mandatory) the list of artifact prefixes like for resource-assigment step in the resource-assigment workflow or its subset
 475
 476 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.
 477
 478 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.
 479
 480 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 assignement result) has a precedence over the value from the *rb profile* and value from the *rb profile* has a precedence over the helm package default override value. Similarly, profile can contain resource files that may extend or ammend the existing files for the original helm package content.
 481
 482 .. figure:: files/vFW_CNF_CDS/helm-overrides.png
 483    :align: center
 484
 485    The overall flow of helm data processing
 486
 487 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.
 488
 489 .. figure:: files/vFW_CNF_CDS/helm-overrides-steps.png
 490    :align: center
 491
 492    The steps of processing of helm data with help of CDS
 493
 494 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.
 495
 496 Beside 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.
 497
 498 In order to provide configuration instantiation capability standard condfig-assign and config-deploy workflows have been changed into imperative workflows with first step responsible for collection of informatino 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-assignent phase and data placed in the AAI and MDSAL.
 499
 500 vFW CNF config-assign workflow is following:
 501
 502 ::
 503
 504     "config-assign": {
 505         "steps": {
 506             "config-setup": {
 507                 "description": "Gather necessary input for config template upload",
 508                 "target": "config-setup-process",
 509                 "activities": [
 510                     {
 511                         "call_operation": "ResourceResolutionComponent.process"
 512                     }
 513                 ],
 514                 "on_success": [
 515                     "config-template"
 516                 ]
 517             },
 518             "config-template": {
 519                 "description": "Generate and upload K8s config template",
 520                 "target": "k8s-config-template",
 521                 "activities": [
 522                     {
 523                         "call_operation": "K8sConfigTemplateComponent.process"
 524                     }
 525                 ]
 526             }
 527         },
 528
 529 vFW CNF config-deploy workflow is following:
 530
 531 ::
 532
 533     "config-deploy": {
 534         "steps": {
 535             "config-setup": {
 536                 "description": "Gather necessary input for config init and status verification",
 537                 "target": "config-setup-process",
 538                 "activities": [
 539                     {
 540                         "call_operation": "ResourceResolutionComponent.process"
 541                     }
 542                 ],
 543                 "on_success": [
 544                     "config-apply"
 545                 ]
 546             },
 547             "config-apply": {
 548                 "description": "Activate K8s config template",
 549                 "target": "k8s-config-apply",
 550                 "activities": [
 551                     {
 552                         "call_operation": "K8sConfigTemplateComponent.process"
 553                     }
 554                 ],
 555                 "on_success": [
 556                     "status-verification-script"
 557                 ]
 558             },
 559
 560
 561 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.
 562
 563 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.
 564
 565 ::
 566
 567     "k8s-config-template": {
 568         "type": "component-k8s-config-template",
 569         "interfaces": {
 570             "K8sConfigTemplateComponent": {
 571                 "operations": {
 572                     "process": {
 573                         "inputs": {
 574                             "artifact-prefix-names": [
 575                                 "helm_vpkg"
 576                             ],
 577                             "resource-assignment-map": {
 578                                 "get_attribute": [
 579                                     "config-setup-process",
 580                                     "",
 581                                     "assignment-map",
 582                                     "config-deploy",
 583                                     "config-deploy-setup"
 584                                 ]
 585                             }
 586                         }
 587                     }
 588                 }
 589             }
 590         },
 591         "artifacts": {
 592             "ssh-service-config": {
 593                 "type": "artifact-k8sconfig-content",
 594                 "file": "Templates/k8s-configs/ssh-service.tar.gz"
 595             },
 596             "ssh-service-config-customizable": {
 597                 "type": "artifact-k8sconfig-content",
 598                 "file": "Templates/k8s-configs/ssh-service-config"
 599             },
 600             "ssh-service-config-customizable-mapping": {
 601                 "type": "artifact-mapping-resource",
 602                 "file": "Templates/k8s-configs/ssh-service-config/ssh-service-mapping.json"
 603             }
 604         }
 605     }
 606
 607 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:
 608
 609 - k8s-rb-definition-name - the name under which RB definition was created - **VF Module Model Invariant ID** in ONAP
 610 - k8s-rb-definition-version - the version of created RB definition name - **VF Module Model Customization ID**  in ONAP
 611 - k8s-rb-config-template-name - (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
 612 - k8s-rb-config-template-source - the source of config template content - name of the artifact of the configuration template. If missing *k8s-rb-config-template-name* is treated as a source
 613 - resource-assignment-map - result of the associated resource assignment step - it may deliver values of inputs if they are not specified directly
 614 - artifact-prefix-names - (mandatory) the list of artifact prefixes like for resource-assigment step in the resource-assigment workflow or its subset
 615
 616 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.
 617
 618 ::
 619
 620     "k8s-config-apply": {
 621         "type": "component-k8s-config-value",
 622         "interfaces": {
 623             "K8sConfigValueComponent": {
 624                 "operations": {
 625                     "process": {
 626                         "inputs": {
 627                             "artifact-prefix-names": [
 628                                 "helm_vpkg"
 629                             ],
 630                             "k8s-config-operation-type": "create",
 631                             "resource-assignment-map": {
 632                                 "get_attribute": [
 633                                     "config-setup-process",
 634                                     "",
 635                                     "assignment-map",
 636                                     "config-deploy",
 637                                     "config-deploy-setup"
 638                                 ]
 639                             }
 640                         }
 641                     }
 642                 }
 643             }
 644         },
 645         "artifacts": {
 646             "ssh-service-default": {
 647                 "type": "artifact-k8sconfig-content",
 648                 "file": "Templates/k8s-configs/ssh-service-config/values.yaml"
 649             },
 650             "ssh-service-config": {
 651                 "type": "artifact-k8sconfig-content",
 652                 "file": "Templates/k8s-configs/ssh-service-values/values.yaml.vtl"
 653             },
 654             "ssh-service-config-mapping": {
 655                 "type": "artifact-mapping-resource",
 656                 "file": "Templates/k8s-configs/ssh-service-values/ssh-service-mapping.json"
 657             }
 658         }
 659     }
 660
 661
 662 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 resource assignment step. The *component-k8s-config-value* inputs are following:
 663
 664 - k8s-rb-config-name - (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
 665 - k8s-rb-config-template-name - (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
 666 - k8s-rb-config-value-source - 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
 667 - k8s-instance-id - (mandatory) the identifier of the rb instance for which the configuration should be applied
 668 - k8s-config-operation-type - the type of the configuration operation to perform: create, update or delete. By default create operation is performed
 669 - resource-assignment-map - result of the associated resource assignment step - it may deliver values of inputs if they are not specified directly
 670 - artifact-prefix-names - (mandatory) the list of artifact prefixes like for resource-assigment step in the resource-assigment workflow or its subset
 671
 672 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).
 673
 674 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.
 675
 676 .. 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.
 677
 678 Instantiation Overview
 679 ----------------------
 680
 681 .. 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.
 682
 683 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.
 684
 685 .. figure:: files/vFW_CNF_CDS/Instantiation_topology.png
 686    :align: center
 687
 688    vFW CNF CDS Use Case Runtime interactions.
 689
 690 PART 1 - ONAP Installation
 691 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 692
 693 1-1 Deployment components
 694 .........................
 695
 696 In order to run the vFW_CNF_CDS use case, we need ONAP Istanbul Release (or later) with at least following components:
 697
 698 =======================================================   ===========
 699 ONAP Component name                                       Describtion
 700 -------------------------------------------------------   -----------
 701 AAI                                                       Required for Inventory Cloud Owner, Customer, Owning Entity, Service, Generic VNF, VF Module
 702 SDC                                                       VSP, VF and Service Modeling of the CNF
 703 DMAAP                                                     Distribution of the onboarding package including CBA to all ONAP components
 704 SO                                                        Required for Macro Orchestration using the generic building blocks
 705 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
 706 SDNC (needs to include netbox and Naming Generation mS)   Provides GENERIC-RESOURCE-API for cloud Instantiation orchestration via CDS.
 707 Policy                                                    Used to Store Naming Policy
 708 AAF                                                       Used for Authentication and Authorization of requests
 709 Portal                                                    Required to access SDC.
 710 MSB                                                       Exposes multicloud interfaces used by SO.
 711 Multicloud                                                K8S plugin part used to pass SO instantiation requests to external Kubernetes cloud region.
 712 Contrib                                                   Chart containing multiple external components. Out of those, we only use Netbox utility in this use-case for IPAM
 713 Robot                                                     Optional. Can be used for running automated tasks, like provisioning cloud customer, cloud region, service subscription, etc ..
 714 Shared Cassandra DB                                       Used as a shared storage for ONAP components that rely on Cassandra DB, like AAI
 715 Shared Maria DB                                           Used as a shared storage for ONAP components that rely on Maria DB, like SDNC, and SO
 716 =======================================================   ===========
 717
 718 1-2 Deployment
 719 ..............
 720
 721 In order to deploy such an instance, follow the `ONAP Deployment Guide`_
 722
 723 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.
 724
 725 **override.yaml** file where enabled: true is set for each component needed in demo (by default all components are disabled).
 726
 727 ::
 728
 729   aai:
 730     enabled: true
 731   aaf:
 732     enabled: true
 733   cassandra:
 734     enabled: true
 735   cds:
 736     enabled: true
 737   contrib:
 738     enabled: true
 739   dmaap:
 740     enabled: true
 741   mariadb-galera:
 742     enabled: true
 743   msb:
 744     enabled: true
 745   multicloud:
 746     enabled: true
 747   policy:
 748     enabled: true
 749   portal:
 750     enabled: true
 751   robot:
 752     enabled: true
 753   sdc:
 754     enabled: true
 755   sdnc:
 756     enabled: true
 757   so:
 758     enabled: true
 759
 760 Then deploy ONAP with Helm with your override file.
 761
 762 ::
 763
 764     helm deploy onap local/onap --namespace onap -f ~/override.yaml
 765
 766 In case redeployment needed `Helm Healer`_ could be a faster and convenient way to redeploy.
 767
 768 ::
 769
 770     helm-healer.sh -n onap -f ~/override.yaml -s /dockerdata-nfs --delete-all
 771
 772 Or redeploy (clean re-deploy also data removed) just wanted components (Helm releases), cds in this example.
 773
 774 ::
 775
 776     helm-healer.sh -f ~/override.yaml -s /dockerdata-nfs/ -n onap -c onap-cds
 777
 778 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*.
 779
 780 ::
 781
 782     {
 783     failed=
 784     for comp in {aaf,aai,dmaap,msb,multicloud,policy,portal,sdc,sdnc,so}; do
 785         if ! ./ete-k8s.sh onap health-$comp; then
 786             failed=$failed,$comp
 787         fi
 788     done
 789     if [ -n "$failed" ]; then
 790         echo "These components failed: $failed"
 791         false
 792     else
 793         echo "Healthcheck successful"
 794     fi
 795     }
 796
 797 And check status of pods, deployments, jobs etc.
 798
 799 ::
 800
 801     kubectl -n onap get pods | grep -vie 'completed' -e 'running'
 802     kubectl -n onap get deploy,sts,jobs
 803
 804
 805 1-3 Post Deployment
 806 ...................
 807
 808 After completing the first part above, we should have a functional ONAP deployment for the Istanbul Release.
 809
 810 We will need to apply a few modifications to the deployed ONAP Istanbul instance in order to run the use case.
 811
 812 Retrieving logins and passwords of ONAP components
 813 ++++++++++++++++++++++++++++++++++++++++++++++++++
 814
 815 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.
 816
 817 ::
 818
 819     kubectl get secret `kubectl get secrets | grep mariadb-galera-db-root-password | awk '{print $1}'` -o jsonpath="{.data.login}" | base64 --decode
 820     kubectl get secret `kubectl get secrets | grep mariadb-galera-db-root-password | awk '{print $1}'` -o jsonpath="{.data.password}" | base64 --decode
 821
 822 In this case login is empty as the secret is dedicated to root user.
 823
 824
 825 Postman collection setup
 826 ++++++++++++++++++++++++
 827
 828 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.
 829
 830 Postman collection is used also to trigger instantiation using SO APIs.
 831
 832 Following steps are needed to setup Postman:
 833
 834 - Import this Postman collection zip
 835
 836   :download:`Postman collection <files/vFW_CNF_CDS/postman.zip>`
 837
 838 - 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.
 839     - `vFW_CNF_CDS.postman_collection.json`
 840     - `vFW_CNF_CDS.postman_environment.json`
 841
 842 - 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.
 843
 844 ::
 845
 846     kubectl -n onap edit svc so-catalog-db-adapter
 847          - .spec.type: ClusterIP
 848          + .spec.type: NodePort
 849          + .spec.ports[0].nodePort: 30120
 850
 851 .. note::  The port number 30120 is used in included Postman collection
 852
 853 - 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:
 854
 855 ::
 856
 857     kubectl edit -n onap svc cds-blueprints-processor-http
 858           - .spec.type: ClusterIP
 859           + .spec.type: NodePort
 860           + .spec.ports[0].nodePort: 30499
 861
 862 .. note::  The port number 30499 is used in included Postman collection
 863
 864 **Postman variables:**
 865
 866 Most of the Postman variables are automated by Postman scripts and environment file provided, but there are few mandatory variables to fill by user.
 867
 868 =====================  ===================
 869 Variable               Description
 870 ---------------------  -------------------
 871 k8s                    ONAP Kubernetes host
 872 sdnc_port              port of sdnc service for accessing MDSAL
 873 service-name           name of service as defined in SDC
 874 service-version        version of service defined in SDC (if service wasn't updated, it should be set to "1.0")
 875 service-instance-name  name of instantiated service (if ending with -{num}, will be autoincremented for each instantiation request)
 876 =====================  ===================
 877
 878 You can get the sdnc_port value with
 879
 880 ::
 881
 882     kubectl -n onap get svc sdnc -o json | jq '.spec.ports[]|select(.port==8282).nodePort'
 883
 884 Automation Environment Setup
 885 ............................
 886
 887 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.
 888
 889 ::
 890
 891   git clone --single-branch --branch istanbul "https://gerrit.onap.org/r/demo"
 892   cd demo/heat/vFW_CNF_CDS/templates
 893
 894 In order to prepare environment for onboarding and instantiation of the use case make sure you have *git*, *make*, *helm* and *pipenv* applications installed.
 895
 896 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:
 897
 898 ::
 899
 900   cd demo/heat/vFW_CNF_CDS/automation
 901
 902 1. Install required packages with
 903 ::
 904
 905     pipenv pipenv install
 906
 907 2. Run virtual python environment
 908 ::
 909
 910     pipenv shell --fancy
 911
 912 3. Add kubeconfig files, one for ONAP cluster, and one for k8s cluster that will host vFW
 913
 914 .. 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.
 915
 916 - artifacts/cluster_kubeconfig - IP address must be reachable by ONAP pods, especially *mutlicloud-k8s* pod
 917
 918 - artifacts/onap_kubeconfig - IP address must be reachable by automation scripts
 919
 920 4. Modify config.py file
 921
 922 - SCENARIO - like described in the `The vFW CNF Use Case`_ section
 923 - NATIVE - when enabled (default) **Native Helm** path will be used, otherwise **Dummy Heat** path will be used (deprecated)
 924 - MACRO_INSTANTIATION - instantiation method used: macro (default) or a'la carte. A'la carte only for the purpose of use with other use cases
 925 - K8S_NAMESPACE - k8s namespace to use for deployment of CNF (vfirewall by default)
 926 - K8S_VERSION - version of the k8s cluster
 927 - K8S_REGION - name of the k8s region from the CLOUD_REGIONS (kud by default)
 928 - CLOUD_REGIONS - configuration of k8s or Openstack regions
 929 - GLOBAL_CUSTOMER_ID - identifier of customer in ONAP
 930 - VENDOR - name of the Vendor in ONAP
 931 - SERVICENAME - **Name of your service model in SDC**
 932 - SKIP_POST_INSTANTIATION - whether post instantiation configuration should be run (it is set indirectly by *SCENARIO*)
 933 - VNF_PARAM_LIST - list of parameters to pass for VNF creation process
 934 - VF_MODULE_PARAM_LIST - list of parameters to pass for VF Module creation
 935
 936 .. note:: For automation script it is necessary to modify only SCENARIO constant. Other constants may be modified if needed.
 937
 938 AAI
 939 ...
 940
 941 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.
 942
 943 Create all these entries into AAI in this order. Postman collection provided in this demo can be used for creating each entry.
 944
 945 **<MANUAL>**
 946 ::
 947
 948     Postman -> Initial ONAP setup -> Create
 949
 950 - Create Customer
 951 - Create Owning-entity
 952 - Create Platform
 953 - Create Project
 954 - Create Line Of Business
 955
 956 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.
 957
 958 **<AUTOMATED>**
 959
 960 This step is performed jointly with onboarding step `3-2 Onboarding`_
 961
 962 Naming Policy
 963 +++++++++++++
 964
 965 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.
 966
 967 This usecase leverages default ONAP naming policy - "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP".
 968 To check that the naming policy is created and pushed OK, we can run the command below from inside any ONAP pod.
 969
 970 ::
 971
 972   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"
 973
 974 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
 975
 976 PART 2 - Installation of managed Kubernetes cluster
 977 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 978
 979 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.
 980
 981 2-1 Installation of Managed Kubernetes
 982 ......................................
 983
 984 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`_.
 985
 986 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.
 987
 988 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:
 989
 990 - ovn4nfv
 991 - Multus
 992 - Virtlet
 993
 994 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
 995 ::
 996
 997     export KUD_ADDONS="virtlet ovn4nfv"
 998
 999 .. 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`_
1000
1001 2-2 Cloud Registration
1002 ......................
1003
1004 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.
1005
1006 **<MANUAL>**
1007
1008 Postman collection have folder/entry for each step. Execute in this order.
1009 ::
1010
1011     Postman -> K8s Cloud Region Registration -> Create
1012
1013 - Create Complex
1014 - Create Cloud Region
1015 - Create Complex-Cloud Region Relationship
1016 - Create Service
1017 - Create Service Subscription
1018 - Create Cloud Tenant
1019 - Create Availability Zone
1020 - Upload Connectivity Info
1021
1022 .. 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.
1023
1024 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.
1025
1026 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
1027
1028 ::
1029
1030     kubectl -n onap exec onap-mariadb-galera-0 -it -- mysql -uroot -psecretpassword -D catalogdb
1031         select * from cloud_sites;
1032         insert into cloud_sites(ID, REGION_ID, IDENTITY_SERVICE_ID, CLOUD_VERSION, CLLI, ORCHESTRATOR) values("k8sregionfour", "k8sregionfour", "DEFAULT_KEYSTONE", "2.5", "clli2", "multicloud");
1033         select * from cloud_sites;
1034         exit
1035
1036 .. note:: The configuration of the new k8s cloud site is documented also here `K8s cloud site config`_
1037
1038 **<AUTOMATED>**
1039
1040 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.
1041
1042 ::
1043
1044     python create_k8s_region.py
1045
1046 PART 3 - Execution of the Use Case
1047 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1048
1049 This part contains all the steps to run the use case by using ONAP GUIs, Postman or Python automation scripts.
1050
1051 3-1 CNF Orchestration Paths in ONAP
1052 ...................................
1053
1054 Following pictures describe the overall sequential flow of the use case in two scenarios: **Dummy Heat** path (with OpenStack adapter) and **Native Helm** path (with CNF Adapter)
1055
1056 Dummy Heat CNF Orchestration (Obsolete)
1057 .......................................
1058
1059 .. warning:: This path is not developed in ONAP since Honolulu release, however ONAP OOM gating process with basic_cnf use case makes sure that basic CNF instantiation with Dummy Heat approach still works. New features from `_REQ-458` and `REQ-627` are integrated and tested only in the Native path.
1060
1061 This orchestration method stands on the grounds of Heat template orchestration mechanisms. In SDC onboarding package needs to contains simple Heat templates that are associated with additional Cloud artifacts. SDC distributes Heat templates to SO and Helm packages to K8sPlugin directly. SO orchestrates the Heat templates without any knowledge about their existence, however the OpenStack adater in SO understands k8s region type for which communication over MSB/Mutlicloud is provided - it handles interaction with K8sPlugin for CNF instantiation.
1062
1063 .. figure:: files/vFW_CNF_CDS/Dummy_Heat_Flow.png
1064    :align: center
1065
1066    vFW CNF CDS Use Case sequence flow for *Dummy Heat* (Frankfurt) path.
1067
1068 Native Helm CNF Orchestration
1069 .............................
1070
1071 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.
1072
1073 .. figure:: files/vFW_CNF_CDS/Native_Helm_Flow.png
1074    :align: center
1075
1076    vFW CNF CDS Use Case sequence flow for *Native Helm* (Guilin+) path.
1077
1078
1079 Kubernetes and Helm Compatibility
1080 .................................
1081
1082 K8sPlugin, in the Istanbul release, 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, K8sPlugin implementation of Helm does not support upgrade operation and such flow is not supported in ONAP orchestration workflows.
1083
1084 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.
1085
1086 3-2 Onboarding
1087 ..............
1088
1089 .. note:: Make sure you have performed `Automation Environment Setup`_ steps before following actions here.
1090
1091 Creating Onboarding Package
1092 +++++++++++++++++++++++++++
1093
1094 Content of the onboarding package can be created with provided Makefile in the *template* folder.
1095
1096 Complete content of both Onboarding Packages for **Dummy Heat**  and **Native Helm** is packaged to the following VSP onboarding package files:
1097
1098 - **Dummy Heat** path: **vfw_k8s_demo.zip**
1099
1100 - **Native Helm** path: **native_vfw_k8s_demo.zip**
1101
1102 .. note::  Procedure requires *make* and *helm* applications installed
1103
1104 ::
1105
1106   git clone --single-branch --branch istanbul "https://gerrit.onap.org/r/demo"
1107   cd demo/heat/vFW_CNF_CDS/templates
1108   make
1109
1110 The result of make operation execution is following:
1111 ::
1112
1113     make clean
1114     make[1]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates'
1115     rm -rf package_dummy/
1116     rm -rf package_native/
1117     rm -rf cba_dummy
1118     rm -f vfw_k8s_demo.zip
1119     rm -f native_vfw_k8s_demo.zip
1120     make[1]: Leaving directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates'
1121     make all
1122     make[1]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates'
1123     mkdir package_dummy/
1124     mkdir package_native/
1125     make -C helm
1126     make[2]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm'
1127     rm -f base_template-*.tgz
1128     rm -f helm_base_template.tgz
1129     rm -f base_template_cloudtech_k8s_charts.tgz
1130     helm package base_template
1131     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
1132     mv base_template-*.tgz helm_base_template.tgz
1133     cp helm_base_template.tgz base_template_cloudtech_k8s_charts.tgz
1134     rm -f vpkg-*.tgz
1135     rm -f helm_vpkg.tgz
1136     rm -f vpkg_cloudtech_k8s_charts.tgz
1137     helm package vpkg
1138     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
1139     mv vpkg-*.tgz helm_vpkg.tgz
1140     cp helm_vpkg.tgz vpkg_cloudtech_k8s_charts.tgz
1141     rm -f vfw-*.tgz
1142     rm -f helm_vfw.tgz
1143     rm -f vfw_cloudtech_k8s_charts.tgz
1144     helm package vfw
1145     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
1146     mv vfw-*.tgz helm_vfw.tgz
1147     cp helm_vfw.tgz vfw_cloudtech_k8s_charts.tgz
1148     rm -f vsn-*.tgz
1149     rm -f helm_vsn.tgz
1150     rm -f vsn_cloudtech_k8s_charts.tgz
1151     helm package vsn
1152     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
1153     mv vsn-*.tgz helm_vsn.tgz
1154     cp helm_vsn.tgz vsn_cloudtech_k8s_charts.tgz
1155     make[2]: Leaving directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm'
1156     mv helm/helm_*.tgz package_native/
1157     mv helm/*.tgz package_dummy/
1158     cp base_dummy/* package_dummy/
1159     cp base_native/* package_native/
1160     cp -r cba cba_dummy
1161     sed -i 's/"helm_/"/g' cba_dummy/Definitions/vFW_CNF_CDS.json
1162     cd cba_dummy/ && zip -r CBA.zip . -x pom.xml .idea/\* target/\*
1163     adding: Definitions/ (stored 0%)
1164     adding: Definitions/artifact_types.json (deflated 69%)
1165     adding: Definitions/data_types.json (deflated 88%)
1166     adding: Definitions/node_types.json (deflated 90%)
1167     adding: Definitions/policy_types.json (stored 0%)
1168     adding: Definitions/relationship_types.json (stored 0%)
1169     adding: Definitions/resources_definition_types.json (deflated 94%)
1170     adding: Definitions/vFW_CNF_CDS.json (deflated 87%)
1171     adding: Scripts/ (stored 0%)
1172     adding: Scripts/kotlin/ (stored 0%)
1173     adding: Scripts/kotlin/README.md (stored 0%)
1174     adding: Templates/ (stored 0%)
1175     adding: Templates/base_template-mapping.json (deflated 89%)
1176     adding: Templates/base_template-template.vtl (deflated 87%)
1177     adding: Templates/k8s-profiles/ (stored 0%)
1178     adding: Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz (stored 0%)
1179     adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ (stored 0%)
1180     adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/manifest.yaml (deflated 35%)
1181     adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/override_values.yaml (stored 0%)
1182     adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json (deflated 51%)
1183     adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-template.yaml.vtl (deflated 56%)
1184     adding: Templates/nf-params-mapping.json (deflated 88%)
1185     adding: Templates/nf-params-template.vtl (deflated 44%)
1186     adding: Templates/vfw-mapping.json (deflated 89%)
1187     adding: Templates/vfw-template.vtl (deflated 87%)
1188     adding: Templates/vnf-mapping.json (deflated 89%)
1189     adding: Templates/vnf-template.vtl (deflated 93%)
1190     adding: Templates/vpkg-mapping.json (deflated 89%)
1191     adding: Templates/vpkg-template.vtl (deflated 87%)
1192     adding: Templates/vsn-mapping.json (deflated 89%)
1193     adding: Templates/vsn-template.vtl (deflated 87%)
1194     adding: TOSCA-Metadata/ (stored 0%)
1195     adding: TOSCA-Metadata/TOSCA.meta (deflated 37%)
1196     cd cba/ && zip -r CBA.zip . -x pom.xml .idea/\* target/\*
1197     adding: Definitions/ (stored 0%)
1198     adding: Definitions/artifact_types.json (deflated 69%)
1199     adding: Definitions/data_types.json (deflated 88%)
1200     adding: Definitions/node_types.json (deflated 90%)
1201     adding: Definitions/policy_types.json (stored 0%)
1202     adding: Definitions/relationship_types.json (stored 0%)
1203     adding: Definitions/resources_definition_types.json (deflated 94%)
1204     adding: Definitions/vFW_CNF_CDS.json (deflated 87%)
1205     adding: Scripts/ (stored 0%)
1206     adding: Scripts/kotlin/ (stored 0%)
1207     adding: Scripts/kotlin/README.md (stored 0%)
1208     adding: Templates/ (stored 0%)
1209     adding: Templates/base_template-mapping.json (deflated 89%)
1210     adding: Templates/base_template-template.vtl (deflated 87%)
1211     adding: Templates/k8s-profiles/ (stored 0%)
1212     adding: Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz (stored 0%)
1213     adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ (stored 0%)
1214     adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/manifest.yaml (deflated 35%)
1215     adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/override_values.yaml (stored 0%)
1216     adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json (deflated 51%)
1217     adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-template.yaml.vtl (deflated 56%)
1218     adding: Templates/nf-params-mapping.json (deflated 88%)
1219     adding: Templates/nf-params-template.vtl (deflated 44%)
1220     adding: Templates/vfw-mapping.json (deflated 89%)
1221     adding: Templates/vfw-template.vtl (deflated 87%)
1222     adding: Templates/vnf-mapping.json (deflated 89%)
1223     adding: Templates/vnf-template.vtl (deflated 93%)
1224     adding: Templates/vpkg-mapping.json (deflated 89%)
1225     adding: Templates/vpkg-template.vtl (deflated 87%)
1226     adding: Templates/vsn-mapping.json (deflated 89%)
1227     adding: Templates/vsn-template.vtl (deflated 87%)
1228     adding: TOSCA-Metadata/ (stored 0%)
1229     adding: TOSCA-Metadata/TOSCA.meta (deflated 37%)
1230     mv cba/CBA.zip package_native/
1231     mv cba_dummy/CBA.zip package_dummy/
1232     cd package_dummy/ && zip -r vfw_k8s_demo.zip .
1233     adding: base_template.env (deflated 22%)
1234     adding: base_template.yaml (deflated 59%)
1235     adding: base_template_cloudtech_k8s_charts.tgz (stored 0%)
1236     adding: CBA.zip (stored 0%)
1237     adding: MANIFEST.json (deflated 84%)
1238     adding: vfw.env (deflated 23%)
1239     adding: vfw.yaml (deflated 60%)
1240     adding: vfw_cloudtech_k8s_charts.tgz (stored 0%)
1241     adding: vpkg.env (deflated 13%)
1242     adding: vpkg.yaml (deflated 59%)
1243     adding: vpkg_cloudtech_k8s_charts.tgz (stored 0%)
1244     adding: vsn.env (deflated 15%)
1245     adding: vsn.yaml (deflated 59%)
1246     adding: vsn_cloudtech_k8s_charts.tgz (stored 0%)
1247     cd package_native/ && zip -r native_vfw_k8s_demo.zip .
1248     adding: CBA.zip (stored 0%)
1249     adding: helm_base_template.tgz (stored 0%)
1250     adding: helm_vfw.tgz (stored 0%)
1251     adding: helm_vpkg.tgz (stored 0%)
1252     adding: helm_vsn.tgz (stored 0%)
1253     adding: MANIFEST.json (deflated 71%)
1254     mv package_dummy/vfw_k8s_demo.zip .
1255     mv package_native/native_vfw_k8s_demo.zip .
1256   $
1257
1258 Import this package into SDC and follow onboarding steps.
1259
1260 Service Creation with SDC
1261 +++++++++++++++++++++++++
1262
1263 **<MANUAL>**
1264
1265 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`_
1266
1267 Onboard VSP
1268
1269 - Remember during VSP onboard to choose "Network Package" Onboarding procedure
1270
1271 Create VF and Service
1272 Service -> Properties Assignment -> Choose VF (at right box):
1273
1274 - sdnc_artifact_name - vnf
1275 - sdnc_model_name - vFW_CNF_CDS
1276 - sdnc_model_version - 8.0.0
1277 - skip_post_instantiation_configuration - True
1278
1279 .. note:: Since Honolulu skip_post_instantiation_configuration flag can be set to *False* if we want to run config-assign/config-deploy operations.
1280
1281 **<AUTOMATED>**
1282 .. note:: The onboarding packages for **Dummy Heat** and **Native Helm** path contain different CBA packages but with the same version and number. In consequence, when one VSP is distributed it replaces the CBA package of the other one and you can instantiate service only for the vFW CNF service service model distributed as a last one. If you want to instantiate vFW CNF service, make sure you have fresh distribution of vFW CNF service model.
1283
1284 ::
1285
1286     python onboarding.py
1287
1288 Distribution Of Service
1289 +++++++++++++++++++++++
1290
1291 **<MANUAL>**
1292
1293 Distribute service.
1294
1295 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:
1296
1297 - SDC:
1298
1299     SDC Catalog database should have our service now defined.
1300
1301     ::
1302
1303         Postman -> LCM -> [SDC] Catalog Service
1304
1305     ::
1306
1307         {
1308             "uuid": "64dd38f3-2307-4e0a-bc98-5c2cbfb260b6",
1309             "invariantUUID": "cd1a5c2d-2d4e-4d62-ac10-a5fe05e32a22",
1310             "name": "vfw_cnf_cds_svc",
1311             "version": "1.0",
1312             "toscaModelURL": "/sdc/v1/catalog/services/64dd38f3-2307-4e0a-bc98-5c2cbfb260b6/toscaModel",
1313             "category": "Network L4+",
1314             "lifecycleState": "CERTIFIED",
1315             "lastUpdaterUserId": "cs0008",
1316             "distributionStatus": "DISTRIBUTED"
1317         }
1318
1319     Listing should contain entry with our service name **vfw_cnf_cds_svc**.
1320
1321 .. 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.
1322
1323 - SO:
1324
1325     SO Catalog database should have our service NFs defined now.
1326
1327     ::
1328
1329         Postman -> LCM -> [SO] Catalog DB Service xNFs
1330
1331     ::
1332
1333         {
1334             "serviceVnfs": [
1335                 {
1336                     "modelInfo": {
1337                         "modelName": "VfVfwK8sDemoCnfMc202109231",
1338                         "modelUuid": "70edaca8-8c79-468a-aa76-8224cfe686d0",
1339                         "modelInvariantUuid": "7901fc89-a94d-434a-8454-1e27b99dc0e2",
1340                         "modelVersion": "1.0",
1341                         "modelCustomizationUuid": "86dc8af4-aa17-4fc7-9b20-f12160d99718",
1342                         "modelInstanceName": "vfw_cnf_cds_vsp 0"
1343                     },
1344                     "toscaNodeType": "org.openecomp.resource.vf.VfwCnfCdsVsp",
1345                     "nfFunction": null,
1346                     "nfType": null,
1347                     "nfRole": null,
1348                     "nfNamingCode": null,
1349                     "multiStageDesign": "false",
1350                     "vnfcInstGroupOrder": null,
1351                     "resourceInput": "TBD",
1352                     "vfModules": [
1353                         {
1354                             "modelInfo": {
1355                                 "modelName": "VfVfwK8sDemoCnfMc202109231..helm_base_template..module-4",
1356                                 "modelUuid": "a9f5d65f-20c3-485c-8cf9-eda9ea94300e",
1357                                 "modelInvariantUuid": "7888f606-3ee8-4edb-b96d-467fead6ee4f",
1358                                 "modelVersion": "1",
1359                                 "modelCustomizationUuid": "b9faba47-d03d-4ba1-a117-4c19632b2136"
1360                             },
1361                             "isBase": false,
1362                             "vfModuleLabel": "base_template",
1363                             "initialCount": 1,
1364                             "hasVolumeGroup": false
1365                         },
1366                         {
1367                             "modelInfo": {
1368                                 "modelName": "VfVfwK8sDemoCnfMc202109293..helm_vsn..module-1",
1369                                 "modelUuid": "8e72ed23-4842-471a-ad83-6a4d285c48e1",
1370                                 "modelInvariantUuid": "4f5a8a02-0dc6-4387-b86e-bd352f711e18",
1371                                 "modelVersion": "1",
1372                                 "modelCustomizationUuid": "ab5614d6-25c2-4863-bad3-93e354b4d5ba"
1373                             },
1374                             "isBase": false,
1375                             "vfModuleLabel": "vsn",
1376                             "initialCount": 0,
1377                             "hasVolumeGroup": false
1378                         },
1379                         {
1380                             "modelInfo": {
1381                                 "modelName": "VfVfwK8sDemoCnfMc202109293..helm_vpkg..module-2",
1382                                 "modelUuid": "64f9d622-a8c1-4992-ba35-abdc13f87660",
1383                                 "modelInvariantUuid": "88d8d71a-30c9-4e00-a6b9-bd86bae7ed37",
1384                                 "modelVersion": "1",
1385                                 "modelCustomizationUuid": "37ab4199-19aa-4f63-9a11-d31b8c25ce46"
1386                             },
1387                             "isBase": false,
1388                             "vfModuleLabel": "vpkg",
1389                             "initialCount": 0,
1390                             "hasVolumeGroup": false
1391                         },
1392                         {
1393                             "modelInfo": {
1394                                 "modelName": "VfVfwK8sDemoCnfMc202109293..helm_vfw..module-3",
1395                                 "modelUuid": "f6f62096-d5cc-474e-82c7-655e7d6628b2",
1396                                 "modelInvariantUuid": "6077ce70-3a1d-47e6-87a0-6aed6a29b089",
1397                                 "modelVersion": "1",
1398                                 "modelCustomizationUuid": "879cda5e-7af9-43d2-bd6c-50e330ab328e"
1399                             },
1400                             "isBase": false,
1401                             "vfModuleLabel": "vfw",
1402                             "initialCount": 0,
1403                             "hasVolumeGroup": false
1404                         }
1405                     ],
1406                     "groups": []
1407                 }
1408             ]
1409         }
1410
1411 .. 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*
1412
1413 - SDNC:
1414
1415     SDNC should have it's database updated with *sdnc_* properties that were set during service modeling.
1416
1417 .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_
1418
1419
1420 ::
1421
1422     kubectl -n onap exec onap-mariadb-galera-0 -it -- sh
1423     mysql -uroot -psecretpassword -D sdnctl
1424             MariaDB [sdnctl]> select sdnc_model_name, sdnc_model_version, sdnc_artifact_name from VF_MODEL WHERE customization_uuid = '86dc8af4-aa17-4fc7-9b20-f12160d99718';
1425             +-----------------+--------------------+--------------------+
1426             | sdnc_model_name | sdnc_model_version | sdnc_artifact_name |
1427             +-----------------+--------------------+--------------------+
1428             | vFW_CNF_CDS     | 8.0.0              | vnf                |
1429             +-----------------+--------------------+--------------------+
1430             1 row in set (0.00 sec)
1431
1432
1433 .. note:: customization_uuid value is the modelCustomizationUuid of the VNF (serviceVnfs response in 2nd Postman call from SO Catalog DB)
1434
1435 - CDS:
1436
1437     CDS should onboard CBA uploaded as part of VF.
1438
1439     ::
1440
1441         Postman -> Distribution Verification -> [CDS] List CBAs
1442
1443     ::
1444
1445                 [
1446                         {
1447                                 "blueprintModel": {
1448                                         "id": "c505e516-b35d-4181-b1e2-bcba361cfd0a",
1449                                         "artifactUUId": null,
1450                                         "artifactType": "SDNC_MODEL",
1451                                         "artifactVersion": "8.0.0",
1452                                         "artifactDescription": "Controller Blueprint for vFW_CNF_CDS:8.0.0",
1453                                         "internalVersion": null,
1454                                         "createdDate": "2020-05-29T06:02:20.000Z",
1455                                         "artifactName": "vFW_CNF_CDS",
1456                                         "published": "N",
1457                                         "updatedBy": "Samuli Silvius <s.silvius@partner.samsung.com>",
1458                                         "tags": "Samuli Silvius, Lukasz Rajewski, vFW_CNF_CDS"
1459                                 }
1460                         }
1461                 ]
1462
1463     The list should have the matching entries with SDNC database:
1464
1465     - sdnc_model_name == artifactName
1466     - sdnc_model_version == artifactVersion
1467
1468     You can also use Postman to download CBA for further verification but it's fully optional.
1469
1470     ::
1471
1472         Postman -> Distribution Verification -> [CDS] CBA Download
1473
1474 - K8splugin:
1475
1476     K8splugin should onboard 4 resource bundles related to helm resources:
1477
1478     ::
1479
1480         Postman -> Distribution Verification -> [K8splugin] List Resource Bundle Definitions
1481
1482     ::
1483
1484                 [
1485                     {
1486                         "rb-name": "a9f5d65f-20c3-485c-8cf9-eda9ea94300e",
1487                         "rb-version": "b9faba47-d03d-4ba1-a117-4c19632b2136",
1488                         "chart-name": "base_template",
1489                         "description": "",
1490                         "labels": {
1491                             "vf_module_model_name": "VfVfwK8sDemoCnfMc202109231..helm_base_template..module-4",
1492                             "vf_module_model_uuid": "7888f606-3ee8-4edb-b96d-467fead6ee4f"
1493                         }
1494                     },
1495                     {
1496                         "rb-name": "f6f62096-d5cc-474e-82c7-655e7d6628b2",
1497                         "rb-version": "879cda5e-7af9-43d2-bd6c-50e330ab328e",
1498                         "chart-name": "vfw",
1499                         "description": "",
1500                         "labels": {
1501                             "vf_module_model_name": "VfVfwK8sDemoCnfMc202109293..helm_vfw..module-3",
1502                             "vf_module_model_uuid": "6077ce70-3a1d-47e6-87a0-6aed6a29b089"
1503                         }
1504                     },
1505                     {
1506                         "rb-name": "8e72ed23-4842-471a-ad83-6a4d285c48e1",
1507                         "rb-version": "ab5614d6-25c2-4863-bad3-93e354b4d5ba",
1508                         "chart-name": "vsn",
1509                         "description": "",
1510                         "labels": {
1511                             "vf_module_model_name": "VfVfwK8sDemoCnfMc202109293..helm_vsn..module-1",
1512                             "vf_module_model_uuid": "4f5a8a02-0dc6-4387-b86e-bd352f711e18"
1513                         }
1514                     },
1515                     {
1516                         "rb-name": "64f9d622-a8c1-4992-ba35-abdc13f87660",
1517                         "rb-version": "37ab4199-19aa-4f63-9a11-d31b8c25ce46",
1518                         "chart-name": "vpkg",
1519                         "description": "",
1520                         "labels": {
1521                             "vf_module_model_name": "VfVfwK8sDemoCnfMc202109293..helm_vpkg..module-2",
1522                             "vf_module_model_uuid": "88d8d71a-30c9-4e00-a6b9-bd86bae7ed37"
1523                         }
1524                     }
1525                 ]
1526
1527 **<AUTOMATED>**
1528
1529 Distribution is a part of the onboarding step and at this stage is performed
1530
1531 3-3 CNF Instantiation
1532 .....................
1533
1534 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.
1535
1536 **<MANUAL>**
1537
1538 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:
1539
1540 ::
1541
1542     Postman -> LCM -> 1.[SDC] Catalog Service
1543
1544 ::
1545
1546     Postman -> LCM -> 2. [SO] Catalog DB Service xNFs
1547
1548 Now actual instantiation can be triggered with:
1549
1550 ::
1551
1552     Postman -> LCM -> 3. [SO] Self-Serve Service Assign & Activate
1553
1554 **<AUTOMATED>**
1555
1556 Required inputs for instantiation process are taken from the *config.py* file.
1557 ::
1558
1559     python instantiation.py
1560
1561
1562 Finally, to follow the progress of instantiation request with SO's GET request:
1563
1564 **<MANUAL>**
1565
1566 ::
1567
1568     Postman -> LCM -> 4. [SO] Infra Active Requests
1569
1570 The successful reply payload in that query should start like this:
1571
1572 ::
1573
1574     {
1575       "requestStatus": "COMPLETE",
1576       "statusMessage": "Macro-Service-createInstance request was executed correctly.",
1577       "flowStatus": "Successfully completed all Building Blocks",
1578       "progress": 100,
1579       "startTime": 1590996766000,
1580       "endTime": 1590996945000,
1581       "source": "Postman",
1582       "vnfId": "93b3350d-ed6f-413b-9cc5-a158c1676eb0",
1583       "tenantId": "aaaa",
1584       "requestBody": "**REDACTED FOR READABILITY**",
1585       "lastModifiedBy": "CamundaBPMN",
1586       "modifyTime": "2020-06-01T07:35:45.000+0000",
1587       "cloudRegion": "k8sregionfour",
1588       "serviceInstanceId": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72",
1589       "serviceInstanceName": "vfw-cnf-16",
1590       "requestScope": "service",
1591       "requestAction": "createInstance",
1592       "requestorId": "11c2ddb7-4659-4bf0-a685-a08dcbb5a099",
1593       "requestUrl": "http://infra:30277/onap/so/infra/serviceInstantiation/v7/serviceInstances",
1594       "tenantName": "k8stenant",
1595       "cloudApiRequests": [],
1596       "requestURI": "6a369c8e-d492-4ab5-a107-46804eeb7873",
1597       "_links": {
1598         "self": {
1599           "href": "http://infra:30277/infraActiveRequests/6a369c8e-d492-4ab5-a107-46804eeb7873"
1600         },
1601         "infraActiveRequests": {
1602           "href": "http://infra:30277/infraActiveRequests/6a369c8e-d492-4ab5-a107-46804eeb7873"
1603         }
1604       }
1605     }
1606
1607
1608 Progress can be also followed also with `SO Monitoring`_ dashboard.
1609
1610 Service Instance Termination
1611 ++++++++++++++++++++++++++++
1612
1613 Service instance can be terminated with the following postman call:
1614
1615 **<MANUAL>**
1616 ::
1617
1618     Postman -> LCM -> 5. [SO] Service Delete
1619
1620 **<AUTOMATED>**
1621 ::
1622
1623     python delete.py
1624
1625 .. 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.
1626
1627 Second Service Instance Instantiation
1628 +++++++++++++++++++++++++++++++++++++
1629
1630 To finally verify that all the work done within this demo, it should be possible to instantiate second vFW instance successfully.
1631
1632 Trigger new instance createion. You can use previous call or a separate one that will utilize profile templating mechanism implemented in CBA:
1633
1634 **<MANUAL>**
1635 ::
1636
1637     Postman -> LCM -> 6. [SO] Self-Serve Service Assign & Activate - Second
1638
1639 **<AUTOMATED>**
1640
1641 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.
1642 ::
1643
1644     python onboarding.py
1645     python instantiation.py
1646
1647 3-4 Results and Logs
1648 ....................
1649
1650 Now multiple instances of Kubernetes variant of vFW are running in target VIM (KUD deployment).
1651
1652 .. figure:: files/vFW_CNF_CDS/vFW_Instance_In_Kubernetes.png
1653    :align: center
1654
1655    vFW Instance In Kubernetes
1656
1657 **<MANUAL>**
1658
1659 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.
1660
1661 ::
1662
1663     Postman -> Instantiation verification**
1664
1665 Execute example Postman queries and check example section to see the valid results.
1666
1667 ==========================    =================
1668 Verify Target                 Postman query
1669 --------------------------    -----------------
1670 Service Instances in AAI      **Postman -> Instantiation verification -> [AAI] List Service Instances**
1671 Service Instances in MDSAL    **Postman -> Instantiation verification -> [SDNC] GR-API MD-SAL Services**
1672 K8S Instances in KUD          **Postman -> Instantiation verification -> [K8splugin] List Instances**
1673 ==========================    =================
1674
1675 .. note:: "[AAI] List vServers <Empty>" Request won't return any vserver info from AAI, as currently such information are not provided during instantiation process.
1676
1677
1678 Query also directly from VIM:
1679
1680 ::
1681
1682     #
1683     ubuntu@kud-host:~$ kubectl get pods,svc,networks,cm,network-attachment-definition,deployments
1684     NAME                                                            READY   STATUS    RESTARTS   AGE
1685     pod/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f-7cfb9949d9-8b5vg   1/1     Running   0          22s
1686     pod/vfw-19571429-4af4-49b3-af65-2eb1f97bba43-75cd7c6f76-4gqtz   1/1     Running   0          11m
1687     pod/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-f4485d485-pln8m    1/1     Running   0          11m
1688     pod/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-6f8cff54d-dvw4j    1/1     Running   0          32s
1689     pod/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-5879c56fd-q59l7    2/2     Running   0          11m
1690     pod/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-5889b7455-96j9d    2/2     Running   0          30s
1691
1692     NAME                                                              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
1693     service/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-management-api   NodePort    10.244.43.245   <none>        2831:30831/TCP   11m
1694     service/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-management-api   NodePort    10.244.1.45     <none>        2831:31831/TCP   33s
1695     service/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-darkstat-ui      NodePort    10.244.16.187   <none>        667:30667/TCP    11m
1696     service/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-darkstat-ui      NodePort    10.244.20.229   <none>        667:31667/TCP    30s
1697
1698     NAME                                                                                    AGE
1699     network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-management-network    40s
1700     network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-protected-network     40s
1701     network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-unprotected-network   40s
1702     network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-management-network    11m
1703     network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-protected-network     11m
1704     network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-unprotected-network   11m
1705
1706     NAME                                                           DATA   AGE
1707     configmap/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f-configmap   6      22s
1708     configmap/vfw-19571429-4af4-49b3-af65-2eb1f97bba43-configmap   6      11m
1709     configmap/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-configmap   6      11m
1710     configmap/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-configmap   6      33s
1711     configmap/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-configmap   2      11m
1712     configmap/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-configmap   2      30s
1713
1714     NAME                                                                                       AGE
1715     networkattachmentdefinition.k8s.cni.cncf.io/55118b80-8470-4c99-bfdf-d122cd412739-ovn-nat   40s
1716     networkattachmentdefinition.k8s.cni.cncf.io/567cecc3-9692-449e-877a-ff0b560736be-ovn-nat   11m
1717
1718     NAME                                                             READY   UP-TO-DATE   AVAILABLE   AGE
1719     deployment.extensions/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f   1/1     1            1           22s
1720     deployment.extensions/vfw-19571429-4af4-49b3-af65-2eb1f97bba43   1/1     1            1           11m
1721     deployment.extensions/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e   1/1     1            1           11m
1722     deployment.extensions/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26   1/1     1            1           33s
1723     deployment.extensions/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14   1/1     1            1           11m
1724     deployment.extensions/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b   1/1     1            1           30s
1725
1726
1727 Component Logs From The Execution
1728 +++++++++++++++++++++++++++++++++
1729
1730 **<MANUAL>**
1731
1732 All logs from the use case execution can be retrieved with following
1733
1734 ::
1735
1736     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>
1737
1738 where <COMPONENT_NAME> and <CONTAINER> should be replaced with following keywords respectively:
1739
1740 - so-bpmn-infra, so-bpmn-infra
1741 - so-openstack-adapter, so-openstack-adapter
1742 - so-cnf-adapter, so-cnf-adapter
1743 - sdnc-0, sdnc
1744
1745   From karaf.log all requests (payloads) to CDS can be found by searching following string:
1746
1747   ``'Sending request below to url http://cds-blueprints-processor-http:8080/api/v1/execution-service/process'``
1748
1749 - cds-blueprints-processor, cds-blueprints-processor
1750 - multicloud-k8s, multicloud-k8s
1751 - network-name-gen, network-name-gen,
1752
1753 **Debug log**
1754
1755 In case more detailed logging is needed, here's instructions how to setup DEBUG logging for few components.
1756
1757 - SDNC
1758
1759   ::
1760
1761     kubectl -n onap exec -it onap-sdnc-0 -c sdnc /opt/opendaylight/bin/client log:set DEBUG
1762
1763
1764 - CDS Blueprint Processor
1765
1766   ::
1767
1768     # Edit configmap
1769     kubectl -n onap edit configmap onap-cds-blueprints-processor-configmap
1770
1771     # Edit logback.xml content change root logger level from info to debug.
1772     <root level="debug">
1773         <appender-ref ref="STDOUT"/>
1774     </root>
1775
1776     # Delete the Pods to make changes effective
1777     kubectl -n onap delete pods -l app=cds-blueprints-processor
1778
1779 3-5 Verification of the CNF Status
1780 ..................................
1781
1782 **<MANUAL>**
1783
1784 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
1785
1786 ::
1787
1788     curl -i http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/{rb-instance-id}/status
1789
1790 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.
1791
1792 The same API can be accessed over cnf-adapter endpoint (ClusterIP):
1793
1794 ::
1795
1796     curl -i http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/{rb-instance-id}/status
1797
1798 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:
1799
1800 ::
1801
1802     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
1803
1804 and cnf-adapter endpoint is:
1805
1806 ::
1807
1808     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
1809
1810
1811 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.
1812
1813   :download:`Full Status API Result <files/vFW_CNF_CDS/status-response.json>`
1814
1815 ::
1816
1817     {
1818         "request": {
1819             "rb-name": "vfw",
1820             "rb-version": "plugin_test",
1821             "profile-name": "test_profile",
1822             "release-name": "",
1823             "cloud-region": "kud",
1824             "labels": {
1825                 "testCaseName": "plugin_fw.sh"
1826             },
1827             "override-values": {
1828                 "global.onapPrivateNetworkName": "onap-private-net-test"
1829             }
1830         },
1831         "ready": true,
1832         "resourceCount": 1,
1833         "resourcesStatus": [
1834             {
1835                 "name": "sink-configmap",
1836                 "GVK": {
1837                     "Group": "",
1838                     "Version": "v1",
1839                     "Kind": "ConfigMap"
1840                 },
1841                 "status": {
1842                     "apiVersion": "v1",
1843                     "data": {
1844                         "protected_net_gw": "192.168.20.100",
1845                         "protected_private_net_cidr": "192.168.10.0/24"
1846                     },
1847                     "kind": "ConfigMap",
1848                     "metadata": {
1849                         "creationTimestamp": "2020-09-29T13:36:25Z",
1850                         "labels": {
1851                             "k8splugin.io/rb-instance-id": "practical_nobel"
1852                         },
1853                         "name": "sink-configmap",
1854                         "namespace": "plugin-tests-namespace",
1855                         "resourceVersion": "10720771",
1856                         "selfLink": "/api/v1/namespaces/plugin-tests-namespace/configmaps/sink-configmap",
1857                         "uid": "46c8bec4-980c-455b-9eb0-fb84ac8cc450"
1858                     }
1859                 }
1860             }
1861         ]
1862     }
1863
1864 **<AUTOMATED>**
1865
1866 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 Healtcheck APIs that both are natively exposed in the CDS and can be executed from the script execution functionality in the CDS.
1867
1868 .. figure:: files/vFW_CNF_CDS/healthcheck.png
1869    :scale: 60 %
1870    :align: center
1871
1872    vFW CNF Healthcheck flow concept
1873
1874 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.
1875
1876 ::
1877
1878     "health-check": {
1879         "steps": {
1880             "config-setup": {
1881                 "description": "Gather necessary input for config init and status verification",
1882                 "target": "config-setup-process",
1883                 "activities": [
1884                     {
1885                         "call_operation": "ResourceResolutionComponent.process"
1886                     }
1887                 ],
1888                 "on_success": [
1889                     "config-apply"
1890                 ],
1891                 "on_failure": [
1892                     "handle_error"
1893                 ]
1894             },
1895             "status-verification-script": {
1896                 "description": "Simple status verification script",
1897                 "target": "simple-status-check",
1898                 "activities": [
1899                     {
1900                         "call_operation": "ComponentScriptExecutor.process"
1901                     }
1902                 ],
1903                 "on_success": [
1904                     "health-check-process"
1905                 ],
1906                 "on_failure": [
1907                     "handle_error"
1908                 ]
1909             },
1910             "health-check-process": {
1911                 "description": "Start health check script",
1912                 "target": "health-check-script",
1913                 "activities": [
1914                     {
1915                         "call_operation": "ComponentScriptExecutor.process"
1916                     }
1917                 ],
1918                 "on_success": [
1919                     "collect-results"
1920                 ],
1921                 "on_failure": [
1922                     "handle_error"
1923                 ]
1924             },
1925             "handle_error": {
1926                 "description": "Simple error verification script",
1927                 "target": "simple-error-check",
1928                 "activities": [
1929                     {
1930                         "call_operation": "ComponentScriptExecutor.process"
1931                     }
1932                 ],
1933                 "on_success": [
1934                     "collect-results"
1935                 ]
1936             },
1937             "collect-results": {
1938                 "description": "Final collection of results",
1939                 "target": "collect-results"
1940             }
1941         },
1942
1943
1944 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 dedicated endpoint documented here: `CNF Health Check`_. This workflow is not yet integrated into automation scripts.
1945
1946 3-6 Synchronization of created k8s resources into AAI
1947 .....................................................
1948
1949 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.
1950
1951 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.
1952
1953   :download:`List of K8s Resources <files/vFW_CNF_CDS/k8s-resources-response.json>`
1954
1955   :download:`Generic VNF with modules <files/vFW_CNF_CDS/status-response.json>`
1956
1957   :download:`vPKG VF-Module with related k8s-resource relations <files/vFW_CNF_CDS/vpkg-vf-module-aai.json>`
1958
1959 Currently AAI synchronization is run just after creation  of the vf-module by SO. If any changes occurs after, like new Pods created or some deleted, we do not have this information in AAI by default. In order to force the update of AAI information about the concrete Helm package, the following API can be used with properly modified body (all except the callbackUrl).
1960
1961 ::
1962
1963     curl -i -X POST http://${K8S_NODE_IP}:8090/api/cnf-adapter/v1/aai-update
1964
1965
1966 ::
1967
1968     {
1969         "instanceId": "keen_darwin",
1970         "cloudRegion": "kud",
1971         "cloudOwner": "K8sCloudOwner",
1972         "tenantId": "dca807fa-0d3e-4fb1-85eb-b9e1c03108a3",
1973         "callbackUrl": "http://example",
1974         "genericVnfId": "8b3af2e0-fd66-460d-b928-22f5dac517a6",
1975         "vfModuleId": "a0161551-9d13-47c2-ba4f-896d4ee401d4"
1976     }
1977
1978
1979 PART 4 - Future improvements needed
1980 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1981
1982 Future development areas for this use case:
1983
1984 - Include Closed Loop part of the vFW CNF demo.
1985 - vFW service with Openstack VNF (KUD) and Kubernetes CNF
1986
1987 Future development areas for CNF support:
1988
1989 - Extraction of override values in time of the package onboarding.
1990 - Update of the information in AAI after creation
1991 - Upgrade of the vFW CNF similar to Helm Upgrade through the SDC and SO
1992 - Use multicloud/k8S API v2 (EMCO)
1993
1994 Some of the features from the list above are covered by the Jakarta roadmap described in `REQ-890`_.
1995
1996
1997 .. _ONAP Deployment Guide: https://docs.onap.org/projects/onap-oom/en/guilin/oom_quickstart_guide.html
1998 .. _CDS Documentation: https://docs.onap.org/projects/onap-ccsdk-cds/en/guilin/index.html
1999 .. _vLB use-case: https://wiki.onap.org/pages/viewpage.action?pageId=71838898
2000 .. _vFW_CNF_CDS Model: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates?h=guilin
2001 .. _vFW_CNF_CDS Automation: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/automation?h=guilin
2002 .. _vFW CDS Dublin: https://wiki.onap.org/display/DW/vFW+CDS+Dublin
2003 .. _vFW CBA Model: https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/service-blueprint/vFW?h=elalto
2004 .. _vFW_Helm Model: https://git.onap.org/multicloud/k8s/tree/kud/demo/firewall?h=elalto
2005 .. _vFW_NextGen: https://git.onap.org/demo/tree/heat/vFW_NextGen?h=elalto
2006 .. _vFW EDGEX K8S: https://docs.onap.org/en/elalto/submodules/integration.git/docs/docs_vfw_edgex_k8s.html
2007 .. _vFW EDGEX K8S In ONAP Wiki: https://wiki.onap.org/display/DW/Deploying+vFw+and+EdgeXFoundry+Services+on+Kubernets+Cluster+with+ONAP
2008 .. _KUD github: https://github.com/onap/multicloud-k8s/tree/honolulu/kud/hosting_providers/baremetal
2009 .. _KUD in Wiki: https://wiki.onap.org/display/DW/Kubernetes+Baremetal+deployment+setup+instructions
2010 .. _Multicloud k8s gerrit: https://gerrit.onap.org/r/q/status:open+project:+multicloud/k8s
2011 .. _KUD subproject in github: https://github.com/onap/multicloud-k8s/tree/honolulu/kud
2012 .. _KUD Interface Permission: https://jira.onap.org/browse/MULTICLOUD-1310
2013 .. _Frankfurt CBA Definition: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba/Definitions/vFW_CNF_CDS.json?h=frankfurt
2014 .. _Frankfurt CBA Script: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba/Scripts/kotlin/KotlinK8sProfileUpload.kt?h=frankfurt
2015 .. _SO-3403: https://jira.onap.org/browse/SO-3403
2016 .. _SO-3404: https://jira.onap.org/browse/SO-3404
2017 .. _REQ-182: https://jira.onap.org/browse/REQ-182
2018 .. _REQ-341: https://jira.onap.org/browse/REQ-341
2019 .. _REQ-458: https://jira.onap.org/browse/REQ-458
2020 .. _REQ-627: https://jira.onap.org/browse/REQ-627
2021 .. _REQ-890: https://jira.onap.org/browse/REQ-890
2022 .. _Python SDK: https://docs.onap.org/projects/onap-integration/en/guilin/integration-tooling.html?highlight=python-sdk#python-onapsdk
2023 .. _KUD Jenkins ci/cd verification: https://jenkins.onap.org/job/multicloud-k8s-master-kud-deployment-verify-shell/
2024 .. _K8s cloud site config: https://docs.onap.org/en/guilin/guides/onap-operator/cloud_site/k8s/index.html
2025 .. _SO Monitoring: https://docs.onap.org/projects/onap-so/en/guilin/developer_info/Working_with_so_monitoring.html
2026 .. _Data Dictionary: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba-dd.json?h=guilin
2027 .. _Helm Healer: https://git.onap.org/oom/offline-installer/tree/tools/helm-healer.sh?h=frankfurt
2028 .. _infra_workload: https://docs.onap.org/projects/onap-multicloud-framework/en/latest/specs/multicloud_infra_workload.html?highlight=multicloud
2029 .. _K8s Client Compatibility: https://github.com/kubernetes/client-go
2030 .. _CNF Health Check: https://docs.onap.org/projects/onap-so/en/latest/api/apis/serviceInstances-api.html#healthcheck
2031 .. _K8s Resource in AAI: https://jira.onap.org/browse/ONAPMODEL-37
2032 .. _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