Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1 | .. This work is licensed under a Creative Commons Attribution 4.0 International License. |
| 2 | .. http://creativecommons.org/licenses/by/4.0 |
| 3 | .. Copyright 2020 ONAP |
| 4 | |
| 5 | .. _docs_vFW_CNF_CDS: |
| 6 | |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 7 | :orphan: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 8 | |
| 9 | vFirewall CNF Use Case |
| 10 | ---------------------- |
| 11 | |
| 12 | Source files |
| 13 | ~~~~~~~~~~~~ |
| 14 | - Heat/Helm/CDS models: `vFW_CNF_CDS Model`_ |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 15 | - Automation Scripts: `vFW_CNF_CDS Automation`_ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 16 | |
| 17 | Description |
| 18 | ~~~~~~~~~~~ |
| 19 | This use case is a combination of `vFW CDS Dublin`_ and `vFW EDGEX K8S`_ use cases. The aim is to continue improving Kubernetes based Network Functions (a.k.a CNF) support in ONAP. Use case continues where `vFW EDGEX K8S`_ left and brings CDS support into picture like `vFW CDS Dublin`_ did for the old vFW Use case. Predecessor use case is also documented here `vFW EDGEX K8S In ONAP Wiki`_. |
| 20 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 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: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 22 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 23 | - vFW Kubernetes Helm charts support overrides (previously mostly hardcoded values) |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 24 | - SDC accepts Onboarding Package with many helm packages what allows to keep decomposition of service instance similar to `vFW CDS Dublin`_ |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 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) |
deen1985 | 589467c | 2020-12-28 10:40:03 +0100 | [diff] [blame] | 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 |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 31 | - Combined all models (Heat, Helm, CBA) in to same git repo and a created single onboarding package `vFW_CNF_CDS Model`_ |
| 32 | - Use case does not contain Closed Loop part of the vFW demo. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 33 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 34 | All changes to related ONAP components and Use Case can be found in the following tickets: |
| 35 | |
| 36 | - `REQ-182`_ |
| 37 | - `REQ-341`_ |
| 38 | |
| 39 | **Since Guilin ONAP supports Helm packages as a native onboarding artifacts and SO natively orchestrates Helm packages what brings significant advantages in the future. Also since this release ONAP has first mechanisms for monitoring of the status of deployed CNF resources**. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 40 | |
| 41 | The vFW CNF Use Case |
| 42 | ~~~~~~~~~~~~~~~~~~~~ |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 43 | 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. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 44 | |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 45 | 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. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 46 | |
| 47 | Demo git directory has also `Data Dictionary`_ file (CDS model time resource) included. |
| 48 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 49 | 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. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 50 | |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 51 | Following table describes all the source models to which this demo is based on. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 52 | |
| 53 | =============== ================= =========== |
| 54 | Model Git reference Description |
| 55 | --------------- ----------------- ----------- |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 56 | Heat `vFW_NextGen`_ Heat templates used in original vFW demo but split into multiple vf-modules |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 57 | Helm `vFW_Helm Model`_ Helm templates used in `vFW EDGEX K8S`_ demo |
| 58 | CDS model `vFW CBA Model`_ CDS CBA model used in `vFW CDS Dublin`_ demo |
| 59 | =============== ================= =========== |
| 60 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 61 | .. note:: Since the Guilin release `vFW_CNF_CDS Model`_ contains sources that allow to model and instantiate CNF with VNF/Heat orchestration approach (Frankfurt) and with native Helm orchestration approach. Please follow README.txt description and further documentation here to generate and select appropriate onboarding package which will leverage appropriate SO orchestration path. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 62 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 63 | Modeling Onboarding Package/Helm |
| 64 | ................................ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 65 | |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 66 | 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. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 67 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 68 | The Guilin version of the `vFW_CNF_CDS Model`_ contains files required to create **VSP onboarding packages in two formats**: the **Dummy Heat** (available in Frankfurt release already) one that considers association of each Helm package with dummy heat templates and the **Native Helm** one where each Helm package is standalone and is natively understood in consequence by SO. For both variants of VSP Helm packages are matched to the vf-module concept, so basically each Helm application after instantiation is visible to ONAP as a separate vf-module. The chosen format for onboarding has **crucial** role in the further orchestration approach applied for Helm package instantiation. The **Dummy Heat** will result with orchestration through the **Openstack Adapter** component of SO while **Native Helm** will result with **CNF Adapter**. Both approaches will result with instantiation of the same CNF, however the **Native Helm** approach will be enhanced in the future releases while **Dummy Heat** approach will become deprecated in the future. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 69 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 70 | 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 teamplate and for CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT must be the same, like i.e. *vpg* vf-module in the manifest file below. The name of the CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT artifact is predefined and needs to match the pattern: <vf_module_label>_cloudtech_k8s_charts.tgz. More examples can be found in `Modeling Onboarding Package/Helm`_ section. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 71 | |
| 72 | :: |
| 73 | |
| 74 | { |
| 75 | "name": "virtualFirewall", |
| 76 | "description": "", |
| 77 | "data": [ |
| 78 | { |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 79 | "file": "CBA.zip", |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 80 | "type": "CONTROLLER_BLUEPRINT_ARCHIVE" |
| 81 | }, |
| 82 | { |
| 83 | "file": "base_template.yaml", |
| 84 | "type": "HEAT", |
| 85 | "isBase": "true", |
| 86 | "data": [ |
| 87 | { |
| 88 | "file": "base_template.env", |
| 89 | "type": "HEAT_ENV" |
| 90 | } |
| 91 | ] |
| 92 | }, |
| 93 | { |
| 94 | "file": "base_template_cloudtech_k8s_charts.tgz", |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 95 | "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT" |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 96 | }, |
| 97 | { |
| 98 | "file": "vfw.yaml", |
| 99 | "type": "HEAT", |
| 100 | "isBase": "false", |
| 101 | "data": [ |
| 102 | { |
| 103 | "file": "vfw.env", |
| 104 | "type": "HEAT_ENV" |
| 105 | } |
| 106 | ] |
| 107 | }, |
| 108 | { |
| 109 | "file": "vfw_cloudtech_k8s_charts.tgz", |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 110 | "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT" |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 111 | }, |
| 112 | { |
| 113 | "file": "vpkg.yaml", |
| 114 | "type": "HEAT", |
| 115 | "isBase": "false", |
| 116 | "data": [ |
| 117 | { |
| 118 | "file": "vpkg.env", |
| 119 | "type": "HEAT_ENV" |
| 120 | } |
| 121 | ] |
| 122 | }, |
| 123 | { |
| 124 | "file": "vpkg_cloudtech_k8s_charts.tgz", |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 125 | "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT" |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 126 | }, |
| 127 | { |
| 128 | "file": "vsn.yaml", |
| 129 | "type": "HEAT", |
| 130 | "isBase": "false", |
| 131 | "data": [ |
| 132 | { |
| 133 | "file": "vsn.env", |
| 134 | "type": "HEAT_ENV" |
| 135 | } |
| 136 | ] |
| 137 | }, |
| 138 | { |
| 139 | "file": "vsn_cloudtech_k8s_charts.tgz", |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 140 | "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT" |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 141 | } |
| 142 | ] |
| 143 | } |
| 144 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 145 | 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. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 146 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 147 | :: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 148 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 149 | { |
| 150 | "name": "virtualFirewall", |
| 151 | "description": "", |
| 152 | "data": [ |
| 153 | { |
| 154 | "file": "CBA.zip", |
| 155 | "type": "CONTROLLER_BLUEPRINT_ARCHIVE" |
| 156 | }, |
| 157 | { |
| 158 | "file": "helm_base_template.tgz", |
| 159 | "type": "HELM", |
| 160 | "isBase": "true" |
| 161 | }, |
| 162 | { |
| 163 | "file": "helm_vfw.tgz", |
| 164 | "type": "HELM", |
| 165 | "isBase": "false" |
| 166 | }, |
| 167 | { |
| 168 | "file": "helm_vpkg.tgz", |
| 169 | "type": "HELM", |
| 170 | "isBase": "false" |
| 171 | }, |
| 172 | { |
| 173 | "file": "helm_vsn.tgz", |
| 174 | "type": "HELM", |
| 175 | "isBase": "false" |
| 176 | } |
| 177 | ] |
| 178 | } |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 179 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 180 | .. note:: CDS model (CBA package) is delivered as SDC supported own type CONTROLLER_BLUEPRINT_ARCHIVE but the current limitation of VSP onbarding forces to use the artifact name *CBA.zip* to automaticaly recognize CBA as a CONTROLLER_BLUEPRINT_ARCHIVE. |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 181 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 182 | CDS Model (CBA) |
| 183 | ............... |
| 184 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 185 | 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`_. |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 186 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 187 | 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. |
| 188 | |
deen1985 | 589467c | 2020-12-28 10:40:03 +0100 | [diff] [blame] | 189 | As K8S application was split into multiple Helm packages to match vf-modules, CBA modeling follows the same and for each vf-module there's own template in CBA package. The list of artifact with the templates is different for **Dummy Heat** and **Native Helm** approach. The second one has artifact names starting with *helm_* prefix, in the same way like names of artifacts in the MANIFEST file of VSP differs. The **Dummy Heat** artifacts' list is following: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 190 | |
| 191 | :: |
| 192 | |
| 193 | "artifacts" : { |
| 194 | "base_template-template" : { |
| 195 | "type" : "artifact-template-velocity", |
| 196 | "file" : "Templates/base_template-template.vtl" |
| 197 | }, |
| 198 | "base_template-mapping" : { |
| 199 | "type" : "artifact-mapping-resource", |
| 200 | "file" : "Templates/base_template-mapping.json" |
| 201 | }, |
| 202 | "vpkg-template" : { |
| 203 | "type" : "artifact-template-velocity", |
| 204 | "file" : "Templates/vpkg-template.vtl" |
| 205 | }, |
| 206 | "vpkg-mapping" : { |
| 207 | "type" : "artifact-mapping-resource", |
| 208 | "file" : "Templates/vpkg-mapping.json" |
| 209 | }, |
| 210 | "vfw-template" : { |
| 211 | "type" : "artifact-template-velocity", |
| 212 | "file" : "Templates/vfw-template.vtl" |
| 213 | }, |
| 214 | "vfw-mapping" : { |
| 215 | "type" : "artifact-mapping-resource", |
| 216 | "file" : "Templates/vfw-mapping.json" |
| 217 | }, |
| 218 | "vnf-template" : { |
| 219 | "type" : "artifact-template-velocity", |
| 220 | "file" : "Templates/vnf-template.vtl" |
| 221 | }, |
| 222 | "vnf-mapping" : { |
| 223 | "type" : "artifact-mapping-resource", |
| 224 | "file" : "Templates/vnf-mapping.json" |
| 225 | }, |
| 226 | "vsn-template" : { |
| 227 | "type" : "artifact-template-velocity", |
| 228 | "file" : "Templates/vsn-template.vtl" |
| 229 | }, |
| 230 | "vsn-mapping" : { |
| 231 | "type" : "artifact-mapping-resource", |
| 232 | "file" : "Templates/vsn-mapping.json" |
| 233 | } |
| 234 | } |
| 235 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 236 | The **Native Helm** artifacts' list is following: |
| 237 | |
| 238 | :: |
| 239 | |
| 240 | "artifacts" : { |
| 241 | "helm_base_template-template" : { |
| 242 | "type" : "artifact-template-velocity", |
| 243 | "file" : "Templates/base_template-template.vtl" |
| 244 | }, |
| 245 | "helm_base_template-mapping" : { |
| 246 | "type" : "artifact-mapping-resource", |
| 247 | "file" : "Templates/base_template-mapping.json" |
| 248 | }, |
| 249 | "helm_vpkg-template" : { |
| 250 | "type" : "artifact-template-velocity", |
| 251 | "file" : "Templates/vpkg-template.vtl" |
| 252 | }, |
| 253 | "helm_vpkg-mapping" : { |
| 254 | "type" : "artifact-mapping-resource", |
| 255 | "file" : "Templates/vpkg-mapping.json" |
| 256 | }, |
| 257 | "helm_vfw-template" : { |
| 258 | "type" : "artifact-template-velocity", |
| 259 | "file" : "Templates/vfw-template.vtl" |
| 260 | }, |
| 261 | "helm_vfw-mapping" : { |
| 262 | "type" : "artifact-mapping-resource", |
| 263 | "file" : "Templates/vfw-mapping.json" |
| 264 | }, |
| 265 | "vnf-template" : { |
| 266 | "type" : "artifact-template-velocity", |
| 267 | "file" : "Templates/vnf-template.vtl" |
| 268 | }, |
| 269 | "vnf-mapping" : { |
| 270 | "type" : "artifact-mapping-resource", |
| 271 | "file" : "Templates/vnf-mapping.json" |
| 272 | }, |
| 273 | "helm_vsn-template" : { |
| 274 | "type" : "artifact-template-velocity", |
| 275 | "file" : "Templates/vsn-template.vtl" |
| 276 | }, |
| 277 | "helm_vsn-mapping" : { |
| 278 | "type" : "artifact-mapping-resource", |
| 279 | "file" : "Templates/vsn-mapping.json" |
| 280 | } |
| 281 | } |
| 282 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 283 | Only **resource-assignment** workflow of the CBA model is utilized in this demo. If final CBA model contains also **config-deploy** workflow it's there just to keep parity with original vFW CBA (for VMs). Same applies for the related template *Templates/nf-params-template.vtl* and it's mapping file. |
| 284 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 285 | Another advance of the presented use case over solution presented in the Dublin release is possibility of the automatic generation and upload to multicloud/k8s plugin the RB profile content. |
| 286 | 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 |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 287 | modify existing k8s helm templates for each create CNF instance. It opens another level of CNF customization, much more than customization of helm package with override values. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 288 | |
| 289 | :: |
| 290 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 291 | --- |
| 292 | version: v1 |
| 293 | type: |
| 294 | values: “override_values.yaml” |
| 295 | configresource: |
| 296 | - filepath: resources/deployment.yaml |
| 297 | chartpath: templates/deployment.yaml |
| 298 | |
| 299 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 300 | 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. |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 301 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 302 | 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. |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 303 | |
| 304 | :: |
| 305 | |
| 306 | "resource-assignment": { |
| 307 | "steps": { |
| 308 | "resource-assignment": { |
| 309 | "description": "Resource Assign Workflow", |
| 310 | "target": "resource-assignment", |
| 311 | "activities": [ |
| 312 | { |
| 313 | "call_operation": "ResourceResolutionComponent.process" |
| 314 | } |
| 315 | ], |
| 316 | "on_success": [ |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 317 | "profile-upload" |
| 318 | ] |
| 319 | }, |
| 320 | "profile-upload": { |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 321 | "description": "Generate and upload K8s Profile", |
| 322 | "target": "k8s-profile-upload", |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 323 | "activities": [ |
| 324 | { |
| 325 | "call_operation": "ComponentScriptExecutor.process" |
| 326 | } |
| 327 | ] |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 328 | } |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 329 | }, |
| 330 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 331 | .. note:: In the Frankfurt reelase profile upload was implementes as a custom Kotlin script included into the CBA. It was responsible for upload of K8S profile into multicloud/k8s plugin. It is still a good example of the integration of Kotlin scripting into the CBA. For those interested in this functionaliy we recommend to look into the `Frankfurt CBA Definition`_ and `Frankfurt CBA Script`_. |
| 332 | |
deen1985 | 589467c | 2020-12-28 10:40:03 +0100 | [diff] [blame] | 333 | 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*). |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 334 | |
| 335 | :: |
| 336 | |
| 337 | { |
| 338 | "name": "vpg-management-port", |
| 339 | "property": { |
| 340 | "description": "The number of node port for ssh service of vpg", |
| 341 | "type": "integer", |
| 342 | "default": "0" |
| 343 | }, |
| 344 | "input-param": false, |
| 345 | "dictionary-name": "vpg-management-port", |
| 346 | "dictionary-source": "default", |
| 347 | "dependencies": [] |
| 348 | } |
| 349 | |
| 350 | *vpg-management-port* can be included directly into the helm template and such template will be included into vPKG helm package in time of its instantiation. |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 351 | |
| 352 | :: |
| 353 | |
| 354 | apiVersion: v1 |
| 355 | kind: Service |
| 356 | metadata: |
| 357 | name: {{ .Values.vpg_name_0 }}-ssh-access |
| 358 | labels: |
| 359 | vnf-name: {{ .Values.vnf_name }} |
| 360 | vf-module-name: {{ .Values.vpg_name_0 }} |
| 361 | release: {{ .Release.Name }} |
| 362 | chart: {{ .Chart.Name }} |
| 363 | spec: |
| 364 | type: NodePort |
| 365 | ports: |
| 366 | - port: 22 |
| 367 | nodePort: ${vpg-management-port} |
| 368 | selector: |
| 369 | vf-module-name: {{ .Values.vpg_name_0 }} |
| 370 | release: {{ .Release.Name }} |
| 371 | chart: {{ .Chart.Name }} |
| 372 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 373 | |
| 374 | 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. |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 375 | |
| 376 | :: |
| 377 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 378 | "k8s-profile-upload": { |
| 379 | "type": "component-k8s-profile-upload", |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 380 | "interfaces": { |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 381 | "K8sProfileUploadComponent": { |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 382 | "operations": { |
| 383 | "process": { |
| 384 | "inputs": { |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 385 | "artifact-prefix-names": { |
| 386 | "get_input": "template-prefix" |
| 387 | }, |
| 388 | "resource-assignment-map": { |
| 389 | "get_attribute": [ |
| 390 | "resource-assignment", |
| 391 | "assignment-map" |
| 392 | ] |
| 393 | } |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 394 | } |
| 395 | } |
| 396 | } |
| 397 | } |
| 398 | }, |
| 399 | "artifacts": { |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 400 | "vfw-cnf-cds-base-profile": { |
| 401 | "type": "artifact-k8sprofile-content", |
| 402 | "file": "Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz" |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 403 | }, |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 404 | "vfw-cnf-cds-vpkg-profile": { |
| 405 | "type": "artifact-k8sprofile-content", |
| 406 | "file": "Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile" |
| 407 | }, |
| 408 | "vfw-cnf-cds-vpkg-profile-mapping": { |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 409 | "type": "artifact-mapping-resource", |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 410 | "file": "Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json" |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 411 | } |
| 412 | } |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 413 | } |
| 414 | |
deen1985 | 589467c | 2020-12-28 10:40:03 +0100 | [diff] [blame] | 415 | 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 mappimng file with a declaration of the parameters that CDS needs to resolve first, before the Velocity templating is applied to the .vtl files present in the profile content. After Velocity templating the .vtl extensions will be dropped from the file names. The embedded mechanism will include in the profile only files present in the profile MANIFEST file that needs to contain the list of final names of the files to be included into the profile. The figure below shows the idea of profile templating. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 416 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 417 | .. figure:: files/vFW_CNF_CDS/profile-templating.png |
| 418 | :align: center |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 419 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 420 | K8s Profile Templating |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 421 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 422 | 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: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 423 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 424 | - k8s-rb-profile-name – (mandatory) the name of the profile under which it will be created in k8s plugin. Other parameters are required only when profile must be uploaded |
| 425 | - k8s-rb-definition-name – the name under which RB definition was created - **VF Module Model Invariant ID** in ONAP |
| 426 | - k8s-rb-definition-version – the version of created RB definition name - **VF Module Model Version ID** in ONAP |
| 427 | - k8s-rb-profile-namespace – the k8s namespace name associated with profile being created |
| 428 | - k8s-rb-profile-source – the source of profile content - name of the artifact of the profile |
| 429 | - resource-assignment-map – result of the associated resource assignment step |
| 430 | - artifact-prefix-names – (mandatory) the list of artifact prefixes like for resource-assigment step |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 431 | |
deen1985 | 589467c | 2020-12-28 10:40:03 +0100 | [diff] [blame] | 432 | 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 doesn’t contain any content inside and allows instantiation of CNF without the need to define and upload any additional profiles. *vfw-cnf-cds-vpkg-profile* has been prepared to test instantiation of the second modified vFW CNF instance `Second Service Instance Instantiation`_. |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 433 | |
Lukasz Rajewski | dd9bf99 | 2020-12-30 18:43:39 +0100 | [diff] [blame] | 434 | 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 and should be used with *default* profile but may be used also with custom profiles. The overall flow of helm overrides parameters processing is visible on following figure. When *rb definition* (helm package) is being instantiated for specified *rb profile* K8splugin combines override values from the helm pakage, *rb profile* and from the instantiation request - in the respective order. It means that the some from instantiation request (SO request input or CDS resource assignement result) has a precedence over the value from the *rb profile* and value from the *rb profile* has a precedence over the helm package default override value. Similarly, profile can contain resource files that may extend or ammend the existing files for the original helm package content. |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 435 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 436 | .. figure:: files/vFW_CNF_CDS/helm-overrides.png |
| 437 | :align: center |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 438 | |
Lukasz Rajewski | dd9bf99 | 2020-12-30 18:43:39 +0100 | [diff] [blame] | 439 | The overall flow of helm data processing |
| 440 | |
| 441 | 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. |
| 442 | |
| 443 | .. figure:: files/vFW_CNF_CDS/helm-overrides-steps.png |
| 444 | :align: center |
| 445 | |
| 446 | The steps of processing of helm data with help of CDS |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 447 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 448 | 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. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 449 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 450 | .. note:: The CBA for this use case is already enriched and there is no need to perform enrichment process for it. It is also automatically uploaded into CDS in time of the model distribution from the SDC. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 451 | |
| 452 | Instantiation Overview |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 453 | ---------------------- |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 454 | |
deen1985 | 589467c | 2020-12-28 10:40:03 +0100 | [diff] [blame] | 455 | .. note:: Since Guilin release use case is equipped with automated method **<AUTOMATED>** with python scripts to replace Postman method **<MANUAL>** used in Frankfurt. Nevertheless, Postman collection is good to understand the entire process. If a user selects to follow Postman collection, then automation scripts **must not** be used. **For the entire process use only scripts or only Postman collection**. Both options are described in the further steps of this instruction. |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 456 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 457 | 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. |
| 458 | |
| 459 | .. figure:: files/vFW_CNF_CDS/Instantiation_topology.png |
| 460 | :align: center |
| 461 | |
| 462 | vFW CNF CDS Use Case Runtime interactions. |
| 463 | |
| 464 | PART 1 - ONAP Installation |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 465 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 466 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 467 | 1-1 Deployment components |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 468 | ......................... |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 469 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 470 | In order to run the vFW_CNF_CDS use case, we need ONAP Guilin Release (or later) with at least following components: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 471 | |
| 472 | ======================================================= =========== |
| 473 | ONAP Component name Describtion |
| 474 | ------------------------------------------------------- ----------- |
| 475 | AAI Required for Inventory Cloud Owner, Customer, Owning Entity, Service, Generic VNF, VF Module |
| 476 | SDC VSP, VF and Service Modeling of the CNF |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 477 | DMAAP Distribution of the onboarding package including CBA to all ONAP components |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 478 | SO Requires for Macro Orchestration using the generic building blocks |
| 479 | CDS Resolution of cloud parameters including Helm override parameters for the CNF. Creation of the multicloud/k8s profile for CNF instantion. |
| 480 | SDNC (needs to include netbox and Naming Generation mS) Provides GENERIC-RESOURCE-API for cloud Instantiation orchestration via CDS. |
| 481 | Policy Used to Store Naming Policy |
| 482 | AAF Used for Authentication and Authorization of requests |
| 483 | Portal Required to access SDC. |
| 484 | MSB Exposes multicloud interfaces used by SO. |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 485 | Multicloud K8S plugin part used to pass SO instantiation requests to external Kubernetes cloud region. |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 486 | Contrib Chart containing multiple external components. Out of those, we only use Netbox utility in this use-case for IPAM |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 487 | Robot Optional. Can be used for running automated tasks, like provisioning cloud customer, cloud region, service subscription, etc .. |
| 488 | Shared Cassandra DB Used as a shared storage for ONAP components that rely on Cassandra DB, like AAI |
| 489 | Shared Maria DB Used as a shared storage for ONAP components that rely on Maria DB, like SDNC, and SO |
| 490 | ======================================================= =========== |
| 491 | |
| 492 | 1-2 Deployment |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 493 | .............. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 494 | |
| 495 | In order to deploy such an instance, follow the `ONAP Deployment Guide`_ |
| 496 | |
| 497 | 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. |
| 498 | |
| 499 | **override.yaml** file where enabled: true is set for each component needed in demo (by default all components are disabled). |
| 500 | |
| 501 | :: |
| 502 | |
| 503 | aai: |
| 504 | enabled: true |
| 505 | aaf: |
| 506 | enabled: true |
| 507 | cassandra: |
| 508 | enabled: true |
| 509 | cds: |
| 510 | enabled: true |
| 511 | contrib: |
| 512 | enabled: true |
| 513 | dmaap: |
| 514 | enabled: true |
| 515 | mariadb-galera: |
| 516 | enabled: true |
| 517 | msb: |
| 518 | enabled: true |
| 519 | multicloud: |
| 520 | enabled: true |
| 521 | policy: |
| 522 | enabled: true |
| 523 | portal: |
| 524 | enabled: true |
| 525 | robot: |
| 526 | enabled: true |
| 527 | sdc: |
| 528 | enabled: true |
| 529 | sdnc: |
| 530 | enabled: true |
| 531 | so: |
| 532 | enabled: true |
| 533 | |
| 534 | Then deploy ONAP with Helm with your override file. |
| 535 | |
| 536 | :: |
| 537 | |
| 538 | helm deploy onap local/onap --namespace onap -f ~/override.yaml |
| 539 | |
| 540 | In case redeployment needed `Helm Healer`_ could be a faster and convenient way to redeploy. |
| 541 | |
| 542 | :: |
| 543 | |
| 544 | helm-healer.sh -n onap -f ~/override.yaml -s /dockerdata-nfs --delete-all |
| 545 | |
| 546 | Or redeploy (clean re-deploy also data removed) just wanted components (Helm releases), cds in this example. |
| 547 | |
| 548 | :: |
| 549 | |
| 550 | helm-healer.sh -f ~/override.yaml -s /dockerdata-nfs/ -n onap -c onap-cds |
| 551 | |
| 552 | 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*. |
| 553 | |
| 554 | :: |
| 555 | |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 556 | { |
| 557 | failed= |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 558 | for comp in {aaf,aai,dmaap,msb,multicloud,policy,portal,sdc,sdnc,so}; do |
| 559 | if ! ./ete-k8s.sh onap health-$comp; then |
| 560 | failed=$failed,$comp |
| 561 | fi |
| 562 | done |
| 563 | if [ -n "$failed" ]; then |
| 564 | echo "These components failed: $failed" |
| 565 | false |
| 566 | else |
| 567 | echo "Healthcheck successful" |
| 568 | fi |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 569 | } |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 570 | |
| 571 | And check status of pods, deployments, jobs etc. |
| 572 | |
| 573 | :: |
| 574 | |
| 575 | kubectl -n onap get pods | grep -vie 'completed' -e 'running' |
| 576 | kubectl -n onap get deploy,sts,jobs |
| 577 | |
| 578 | |
| 579 | 1-3 Post Deployment |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 580 | ................... |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 581 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 582 | After completing the first part above, we should have a functional ONAP deployment for the Guilin Release. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 583 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 584 | We will need to apply a few modifications to the deployed ONAP Guilin instance in order to run the use case. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 585 | |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 586 | Retrieving logins and passwords of ONAP components |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 587 | ++++++++++++++++++++++++++++++++++++++++++++++++++ |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 588 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 589 | 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. |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 590 | |
| 591 | :: |
| 592 | |
Konrad Bańka | 38af9cf | 2020-06-01 09:36:09 +0200 | [diff] [blame] | 593 | kubectl get secret `kubectl get secrets | grep mariadb-galera-db-root-password | awk '{print $1}'` -o jsonpath="{.data.login}" | base64 --decode |
| 594 | kubectl get secret `kubectl get secrets | grep mariadb-galera-db-root-password | awk '{print $1}'` -o jsonpath="{.data.password}" | base64 --decode |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 595 | |
| 596 | In this case login is empty as the secret is dedicated to root user. |
| 597 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 598 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 599 | Postman collection setup |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 600 | ++++++++++++++++++++++++ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 601 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 602 | 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. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 603 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 604 | Postman collection is used also to trigger instantiation using SO APIs. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 605 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 606 | Following steps are needed to setup Postman: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 607 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 608 | - Import this Postman collection zip |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 609 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 610 | :download:`Postman collection <files/vFW_CNF_CDS/postman.zip>` |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 611 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 612 | - Extract the zip and import Postman collection into Postman. Environment file is provided for reference, it's better to create own environment on your own providing variables as listed in next chapter. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 613 | - `vFW_CNF_CDS.postman_collection.json` |
| 614 | - `vFW_CNF_CDS.postman_environment.json` |
| 615 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 616 | - For use case debugging purposes to get Kubernetes cluster external access to SO CatalogDB (GET operations only), modify SO CatalogDB service to NodePort instead of ClusterIP. You may also create separate own NodePort if you wish, but here we have just edited directly the service with kubectl. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 617 | |
| 618 | :: |
| 619 | |
| 620 | kubectl -n onap edit svc so-catalog-db-adapter |
| 621 | - .spec.type: ClusterIP |
| 622 | + .spec.type: NodePort |
| 623 | + .spec.ports[0].nodePort: 30120 |
| 624 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 625 | .. note:: The port number 30120 is used in included Postman collection |
| 626 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 627 | - You may also want to inspect after SDC distribution if CBA has been correctly delivered to CDS. In order to do it, there are created relevant calls later described in doc, however CDS since Frankfurt doesn't expose blueprints-processor's service as NodePort. This is OPTIONAL but if you'd like to use these calls later, you need to expose service in similar way as so-catalog-db-adapter above: |
| 628 | |
| 629 | :: |
| 630 | |
| 631 | kubectl edit -n onap svc cds-blueprints-processor-http |
| 632 | - .spec.type: ClusterIP |
| 633 | + .spec.type: NodePort |
| 634 | + .spec.ports[0].nodePort: 30499 |
| 635 | |
| 636 | .. note:: The port number 30499 is used in included Postman collection |
| 637 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 638 | **Postman variables:** |
| 639 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 640 | Most of the Postman variables are automated by Postman scripts and environment file provided, but there are few mandatory variables to fill by user. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 641 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 642 | ===================== =================== |
| 643 | Variable Description |
| 644 | --------------------- ------------------- |
| 645 | k8s ONAP Kubernetes host |
| 646 | sdnc_port port of sdnc service for accessing MDSAL |
| 647 | service-name name of service as defined in SDC |
| 648 | service-version version of service defined in SDC (if service wasn't updated, it should be set to "1.0") |
| 649 | service-instance-name name of instantiated service (if ending with -{num}, will be autoincremented for each instantiation request) |
| 650 | ===================== =================== |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 651 | |
| 652 | You can get the sdnc_port value with |
| 653 | |
| 654 | :: |
| 655 | |
| 656 | kubectl -n onap get svc sdnc -o json | jq '.spec.ports[]|select(.port==8282).nodePort' |
| 657 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 658 | Automation Environment Setup |
| 659 | ............................ |
| 660 | |
| 661 | 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. |
| 662 | |
| 663 | :: |
| 664 | |
| 665 | git clone --single-branch --branch guilin "https://gerrit.onap.org/r/demo" |
| 666 | cd demo/heat/vFW_CNF_CDS/templates |
| 667 | |
| 668 | In order to prepare environment for onboarding and instantiation of the use case make sure you have *git*, *make*, *helm* and *pipenv* applications installed. |
| 669 | |
| 670 | 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: |
| 671 | |
| 672 | :: |
| 673 | |
| 674 | cd demo/heat/vFW_CNF_CDS/automation |
| 675 | |
| 676 | 1. Install required packages with |
| 677 | :: |
| 678 | |
| 679 | pipenv pipenv install |
| 680 | |
| 681 | 2. Run virtual python environment |
| 682 | :: |
| 683 | |
| 684 | pipenv shell --fancy |
| 685 | |
| 686 | 3. Add kubeconfig files, one for ONAP cluster, and one for k8s cluster that will host vFW |
| 687 | |
| 688 | .. note:: Both files can be configured after creation of k8s cluster for vFW instance `2-1 Installation of Managed Kubernetes`_. Make sure that they have configured external IP address properly. If any cluster uses self signed certificates set also *insecure-skip-tls-verify* flag in the config file. |
| 689 | |
| 690 | - artifacts/cluster_kubeconfig - IP address must be reachable by ONAP pods, especially *mutlicloud-k8s* pod |
| 691 | |
| 692 | - artifacts/onap_kubeconfig - IP address must be reachable by automation scripts |
| 693 | |
| 694 | 4. Modify config.py file |
| 695 | |
| 696 | - NATIVE - when enabled **Native Helm** path will be used, otherwise **Dummy Heat** path will be used |
| 697 | - CLOUD_REGION - name of your k8s cluster from ONAP perspective |
| 698 | - GLOBAL_CUSTOMER_ID - identifier of customer in ONAP |
| 699 | - VENDOR - name of the Vendor in ONAP |
| 700 | - SERVICENAME - **Name of your service model in SDC** |
| 701 | - CUSTOMER_RESOURCE_DEFINITIONS - add list of CRDs to be installed on non KUD k8s cluster - should be used ony to use some non-KUD cluster like i.e. ONAP one to test instantiation of Helm package. For KUD should be empty list |
| 702 | |
| 703 | .. note:: For automation script it is necessary to modify only NATIVE and SERVICENAME constants. Other constants may be modified if needed. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 704 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 705 | AAI |
| 706 | ... |
| 707 | |
| 708 | 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. |
| 709 | |
| 710 | Create all these entries into AAI in this order. Postman collection provided in this demo can be used for creating each entry. |
| 711 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 712 | **<MANUAL>** |
| 713 | :: |
| 714 | |
| 715 | Postman -> Initial ONAP setup -> Create |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 716 | |
| 717 | - Create Customer |
| 718 | - Create Owning-entity |
| 719 | - Create Platform |
| 720 | - Create Project |
| 721 | - Create Line Of Business |
| 722 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 723 | 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. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 724 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 725 | **<AUTOMATED>** |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 726 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 727 | This step is performed jointly with onboarding step `3-1 Onboarding`_ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 728 | |
| 729 | Naming Policy |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 730 | +++++++++++++ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 731 | |
| 732 | 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. |
| 733 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 734 | This usecase leverages default ONAP naming policy - "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP". |
| 735 | To check that the naming policy is created and pushed OK, we can run the command below from inside any ONAP pod. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 736 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 737 | :: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 738 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 739 | curl --silent -k --user 'healthcheck:zb!XztG34' -X GET "https://policy-api:6969/policy/api/v1/policytypes/onap.policies.Naming/versions/1.0.0/policies/SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP/versions/1.0.0" |
| 740 | |
| 741 | .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 742 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 743 | PART 2 - Installation of managed Kubernetes cluster |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 744 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 745 | |
| 746 | 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. |
| 747 | |
| 748 | 2-1 Installation of Managed Kubernetes |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 749 | ...................................... |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 750 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 751 | 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`_. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 752 | |
| 753 | 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. |
| 754 | |
| 755 | 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: |
| 756 | |
| 757 | - ovn4nfv |
| 758 | - Multus |
| 759 | - Virtlet |
| 760 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 761 | 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 |
| 762 | :: |
| 763 | |
| 764 | export KUD_ADDONS="virtlet ovn4nfv" |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 765 | |
| 766 | 2-2 Cloud Registration |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 767 | ...................... |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 768 | |
| 769 | 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. |
| 770 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 771 | **<MANUAL>** |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 772 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 773 | Postman collection have folder/entry for each step. Execute in this order. |
| 774 | :: |
| 775 | |
| 776 | Postman -> K8s Cloud Region Registration -> Create |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 777 | |
| 778 | - Create Complex |
| 779 | - Create Cloud Region |
| 780 | - Create Complex-Cloud Region Relationship |
| 781 | - Create Service |
| 782 | - Create Service Subscription |
| 783 | - Create Cloud Tenant |
| 784 | - Create Availability Zone |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 785 | - Upload Connectivity Info |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 786 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 787 | .. note:: For "Upload Connectivity Info" call you need to provide kubeconfig file of existing KUD cluster. You can find that kubeconfig on deployed KUD in the directory `~/.kube/config` and this file can be easily copied e.g. via SCP. Please ensure that kubeconfig contains external IP of K8s cluster in kubeconfig and correct it, if it's not. |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 788 | |
| 789 | 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. |
| 790 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 791 | .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_ |
| 792 | |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 793 | :: |
| 794 | |
| 795 | kubectl -n onap exec onap-mariadb-galera-0 -it -- mysql -uroot -psecretpassword -D catalogdb |
| 796 | select * from cloud_sites; |
| 797 | insert into cloud_sites(ID, REGION_ID, IDENTITY_SERVICE_ID, CLOUD_VERSION, CLLI, ORCHESTRATOR) values("k8sregionfour", "k8sregionfour", "DEFAULT_KEYSTONE", "2.5", "clli2", "multicloud"); |
| 798 | select * from cloud_sites; |
| 799 | exit |
| 800 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 801 | .. note:: The configuration of the new k8s cloud site is documented also here `K8s cloud site config`_ |
| 802 | |
| 803 | **<AUTOMATED>** |
| 804 | |
| 805 | 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. |
| 806 | |
| 807 | :: |
| 808 | |
| 809 | python create_k8s_region.py |
| 810 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 811 | PART 3 - Execution of the Use Case |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 812 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 813 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 814 | This part contains all the steps to run the use case by using ONAP GUIs, Postman or Python automation scripts. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 815 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 816 | 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) |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 817 | |
Lukasz Rajewski | dd9bf99 | 2020-12-30 18:43:39 +0100 | [diff] [blame] | 818 | Dummy Heat CNF Orchestration |
| 819 | ............................ |
| 820 | |
| 821 | 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. |
| 822 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 823 | .. figure:: files/vFW_CNF_CDS/Dummy_Heat_Flow.png |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 824 | :align: center |
| 825 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 826 | vFW CNF CDS Use Case sequence flow for *Dummy Heat* (Frankfurt) path. |
| 827 | |
Lukasz Rajewski | dd9bf99 | 2020-12-30 18:43:39 +0100 | [diff] [blame] | 828 | Native Helm CNF Orchestration |
| 829 | ............................. |
| 830 | |
| 831 | 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 future synchronization of data between k8s clusters and AAI is possible. |
| 832 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 833 | .. figure:: files/vFW_CNF_CDS/Native_Helm_Flow.png |
| 834 | :align: center |
| 835 | |
| 836 | vFW CNF CDS Use Case sequence flow for *Native Helm* (Guilin) path. |
| 837 | |
Lukasz Rajewski | dd9bf99 | 2020-12-30 18:43:39 +0100 | [diff] [blame] | 838 | .. warning:: The **Native Helm** path has identified defects in the instantiation process and requires SO images of version 1.7.11 for successfull instantiation of the CNF. Please monitor `SO-3403`_ and `SO-3404`_ tickets to make sure that necessary fixes have been delivered. SO 1.7.11 images were released Dec 24th 2020. Make sure to use them in Your ONAP/Guilin installation. |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 839 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 840 | |
| 841 | 3-1 Onboarding |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 842 | .............. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 843 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 844 | .. note:: Make sure you have performed `Automation Environment Setup`_ steps before following actions here. |
| 845 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 846 | Creating Onboarding Package |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 847 | +++++++++++++++++++++++++++ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 848 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 849 | Content of the onboarding package can be created with provided Makefile in the *template* folder. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 850 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 851 | Complete content of both Onboarding Packages for **Dummy Heat** and **Native Helm** is packaged to the following VSP onboarding package files: |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 852 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 853 | - **Dummy Heat** path: **vfw_k8s_demo.zip** |
| 854 | |
| 855 | - **Native Helm** path: **native_vfw_k8s_demo.zip** |
| 856 | |
| 857 | .. note:: Procedure requires *make* and *helm* applications installed |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 858 | |
| 859 | :: |
| 860 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 861 | git clone --single-branch --branch guilin "https://gerrit.onap.org/r/demo" |
| 862 | cd demo/heat/vFW_CNF_CDS/templates |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 863 | make |
| 864 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 865 | The result of make operation execution is following: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 866 | :: |
| 867 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 868 | make clean |
| 869 | make[1]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates' |
| 870 | rm -rf package_dummy/ |
| 871 | rm -rf package_native/ |
| 872 | rm -rf cba_dummy |
| 873 | rm -f vfw_k8s_demo.zip |
| 874 | rm -f native_vfw_k8s_demo.zip |
| 875 | make[1]: Leaving directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates' |
| 876 | make all |
| 877 | make[1]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates' |
| 878 | mkdir package_dummy/ |
| 879 | mkdir package_native/ |
| 880 | make -C helm |
| 881 | make[2]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm' |
| 882 | rm -f base_template-*.tgz |
| 883 | rm -f helm_base_template.tgz |
| 884 | rm -f base_template_cloudtech_k8s_charts.tgz |
| 885 | helm package base_template |
| 886 | Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/base_template-0.2.0.tgz |
| 887 | mv base_template-*.tgz helm_base_template.tgz |
| 888 | cp helm_base_template.tgz base_template_cloudtech_k8s_charts.tgz |
| 889 | rm -f vpkg-*.tgz |
| 890 | rm -f helm_vpkg.tgz |
| 891 | rm -f vpkg_cloudtech_k8s_charts.tgz |
| 892 | helm package vpkg |
| 893 | Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/vpkg-0.2.0.tgz |
| 894 | mv vpkg-*.tgz helm_vpkg.tgz |
| 895 | cp helm_vpkg.tgz vpkg_cloudtech_k8s_charts.tgz |
| 896 | rm -f vfw-*.tgz |
| 897 | rm -f helm_vfw.tgz |
| 898 | rm -f vfw_cloudtech_k8s_charts.tgz |
| 899 | helm package vfw |
| 900 | Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/vfw-0.2.0.tgz |
| 901 | mv vfw-*.tgz helm_vfw.tgz |
| 902 | cp helm_vfw.tgz vfw_cloudtech_k8s_charts.tgz |
| 903 | rm -f vsn-*.tgz |
| 904 | rm -f helm_vsn.tgz |
| 905 | rm -f vsn_cloudtech_k8s_charts.tgz |
| 906 | helm package vsn |
| 907 | Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/vsn-0.2.0.tgz |
| 908 | mv vsn-*.tgz helm_vsn.tgz |
| 909 | cp helm_vsn.tgz vsn_cloudtech_k8s_charts.tgz |
| 910 | make[2]: Leaving directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm' |
| 911 | mv helm/helm_*.tgz package_native/ |
| 912 | mv helm/*.tgz package_dummy/ |
| 913 | cp base_dummy/* package_dummy/ |
| 914 | cp base_native/* package_native/ |
| 915 | cp -r cba cba_dummy |
| 916 | sed -i 's/"helm_/"/g' cba_dummy/Definitions/vFW_CNF_CDS.json |
| 917 | cd cba_dummy/ && zip -r CBA.zip . -x pom.xml .idea/\* target/\* |
| 918 | adding: Definitions/ (stored 0%) |
| 919 | adding: Definitions/artifact_types.json (deflated 69%) |
| 920 | adding: Definitions/data_types.json (deflated 88%) |
| 921 | adding: Definitions/node_types.json (deflated 90%) |
| 922 | adding: Definitions/policy_types.json (stored 0%) |
| 923 | adding: Definitions/relationship_types.json (stored 0%) |
| 924 | adding: Definitions/resources_definition_types.json (deflated 94%) |
| 925 | adding: Definitions/vFW_CNF_CDS.json (deflated 87%) |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 926 | adding: Scripts/ (stored 0%) |
| 927 | adding: Scripts/kotlin/ (stored 0%) |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 928 | adding: Scripts/kotlin/README.md (stored 0%) |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 929 | adding: Templates/ (stored 0%) |
| 930 | adding: Templates/base_template-mapping.json (deflated 89%) |
| 931 | adding: Templates/base_template-template.vtl (deflated 87%) |
| 932 | adding: Templates/k8s-profiles/ (stored 0%) |
| 933 | adding: Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz (stored 0%) |
| 934 | adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ (stored 0%) |
| 935 | adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/manifest.yaml (deflated 35%) |
| 936 | adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/override_values.yaml (stored 0%) |
| 937 | adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json (deflated 51%) |
| 938 | adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-template.yaml.vtl (deflated 56%) |
| 939 | adding: Templates/nf-params-mapping.json (deflated 88%) |
| 940 | adding: Templates/nf-params-template.vtl (deflated 44%) |
| 941 | adding: Templates/vfw-mapping.json (deflated 89%) |
| 942 | adding: Templates/vfw-template.vtl (deflated 87%) |
| 943 | adding: Templates/vnf-mapping.json (deflated 89%) |
| 944 | adding: Templates/vnf-template.vtl (deflated 93%) |
| 945 | adding: Templates/vpkg-mapping.json (deflated 89%) |
| 946 | adding: Templates/vpkg-template.vtl (deflated 87%) |
| 947 | adding: Templates/vsn-mapping.json (deflated 89%) |
| 948 | adding: Templates/vsn-template.vtl (deflated 87%) |
| 949 | adding: TOSCA-Metadata/ (stored 0%) |
| 950 | adding: TOSCA-Metadata/TOSCA.meta (deflated 37%) |
| 951 | cd cba/ && zip -r CBA.zip . -x pom.xml .idea/\* target/\* |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 952 | adding: Definitions/ (stored 0%) |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 953 | adding: Definitions/artifact_types.json (deflated 69%) |
| 954 | adding: Definitions/data_types.json (deflated 88%) |
| 955 | adding: Definitions/node_types.json (deflated 90%) |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 956 | adding: Definitions/policy_types.json (stored 0%) |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 957 | adding: Definitions/relationship_types.json (stored 0%) |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 958 | adding: Definitions/resources_definition_types.json (deflated 94%) |
| 959 | adding: Definitions/vFW_CNF_CDS.json (deflated 87%) |
| 960 | adding: Scripts/ (stored 0%) |
| 961 | adding: Scripts/kotlin/ (stored 0%) |
| 962 | adding: Scripts/kotlin/README.md (stored 0%) |
| 963 | adding: Templates/ (stored 0%) |
| 964 | adding: Templates/base_template-mapping.json (deflated 89%) |
| 965 | adding: Templates/base_template-template.vtl (deflated 87%) |
| 966 | adding: Templates/k8s-profiles/ (stored 0%) |
| 967 | adding: Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz (stored 0%) |
| 968 | adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ (stored 0%) |
| 969 | adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/manifest.yaml (deflated 35%) |
| 970 | adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/override_values.yaml (stored 0%) |
| 971 | adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json (deflated 51%) |
| 972 | adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-template.yaml.vtl (deflated 56%) |
| 973 | adding: Templates/nf-params-mapping.json (deflated 88%) |
| 974 | adding: Templates/nf-params-template.vtl (deflated 44%) |
| 975 | adding: Templates/vfw-mapping.json (deflated 89%) |
| 976 | adding: Templates/vfw-template.vtl (deflated 87%) |
| 977 | adding: Templates/vnf-mapping.json (deflated 89%) |
| 978 | adding: Templates/vnf-template.vtl (deflated 93%) |
| 979 | adding: Templates/vpkg-mapping.json (deflated 89%) |
| 980 | adding: Templates/vpkg-template.vtl (deflated 87%) |
| 981 | adding: Templates/vsn-mapping.json (deflated 89%) |
| 982 | adding: Templates/vsn-template.vtl (deflated 87%) |
| 983 | adding: TOSCA-Metadata/ (stored 0%) |
| 984 | adding: TOSCA-Metadata/TOSCA.meta (deflated 37%) |
| 985 | mv cba/CBA.zip package_native/ |
| 986 | mv cba_dummy/CBA.zip package_dummy/ |
| 987 | cd package_dummy/ && zip -r vfw_k8s_demo.zip . |
| 988 | adding: base_template.env (deflated 22%) |
| 989 | adding: base_template.yaml (deflated 59%) |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 990 | adding: base_template_cloudtech_k8s_charts.tgz (stored 0%) |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 991 | adding: CBA.zip (stored 0%) |
| 992 | adding: MANIFEST.json (deflated 84%) |
| 993 | adding: vfw.env (deflated 23%) |
| 994 | adding: vfw.yaml (deflated 60%) |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 995 | adding: vfw_cloudtech_k8s_charts.tgz (stored 0%) |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 996 | adding: vpkg.env (deflated 13%) |
| 997 | adding: vpkg.yaml (deflated 59%) |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 998 | adding: vpkg_cloudtech_k8s_charts.tgz (stored 0%) |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 999 | adding: vsn.env (deflated 15%) |
| 1000 | adding: vsn.yaml (deflated 59%) |
| 1001 | adding: vsn_cloudtech_k8s_charts.tgz (stored 0%) |
| 1002 | cd package_native/ && zip -r native_vfw_k8s_demo.zip . |
| 1003 | adding: CBA.zip (stored 0%) |
| 1004 | adding: helm_base_template.tgz (stored 0%) |
| 1005 | adding: helm_vfw.tgz (stored 0%) |
| 1006 | adding: helm_vpkg.tgz (stored 0%) |
| 1007 | adding: helm_vsn.tgz (stored 0%) |
| 1008 | adding: MANIFEST.json (deflated 71%) |
| 1009 | mv package_dummy/vfw_k8s_demo.zip . |
| 1010 | mv package_native/native_vfw_k8s_demo.zip . |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1011 | $ |
| 1012 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1013 | Import this package into SDC and follow onboarding steps. |
| 1014 | |
| 1015 | Service Creation with SDC |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 1016 | +++++++++++++++++++++++++ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1017 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1018 | **<MANUAL>** |
| 1019 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1020 | 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`_ |
| 1021 | |
| 1022 | Onboard VSP |
mrichomme | 0794e67 | 2020-06-09 15:37:37 +0200 | [diff] [blame] | 1023 | |
| 1024 | - Remember during VSP onboard to choose "Network Package" Onboarding procedure |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1025 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1026 | Create VF and Service |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1027 | Service -> Properties Assignment -> Choose VF (at right box): |
mrichomme | 0794e67 | 2020-06-09 15:37:37 +0200 | [diff] [blame] | 1028 | |
| 1029 | - skip_post_instantiation_configuration - True |
| 1030 | - sdnc_artifact_name - vnf |
| 1031 | - sdnc_model_name - vFW_CNF_CDS |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1032 | - sdnc_model_version - 7.0.0 |
| 1033 | |
| 1034 | **<AUTOMATED>** |
| 1035 | .. note:: The onboarding packages for **Dummy Heat** and **Native Helm** path contain different CBA packages but with the same version and number. In consequence, when one VSP is distributed it replaces the CBA package of the other one and you can instantiate service only for the vFW CNF service service model distributed as a last one. If you want to instantiate vFW CNF service, make sure you have fresh distribution of vFW CNF service model. |
| 1036 | |
| 1037 | :: |
| 1038 | |
| 1039 | python onboarding.py |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1040 | |
| 1041 | Distribution Of Service |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 1042 | +++++++++++++++++++++++ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1043 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1044 | **<MANUAL>** |
| 1045 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1046 | Distribute service. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1047 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1048 | 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: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1049 | |
| 1050 | - SDC: |
| 1051 | |
| 1052 | SDC Catalog database should have our service now defined. |
| 1053 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1054 | :: |
| 1055 | |
| 1056 | Postman -> LCM -> [SDC] Catalog Service |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1057 | |
| 1058 | :: |
| 1059 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1060 | { |
| 1061 | "uuid": "64dd38f3-2307-4e0a-bc98-5c2cbfb260b6", |
| 1062 | "invariantUUID": "cd1a5c2d-2d4e-4d62-ac10-a5fe05e32a22", |
| 1063 | "name": "vfw_cnf_cds_svc", |
| 1064 | "version": "1.0", |
| 1065 | "toscaModelURL": "/sdc/v1/catalog/services/64dd38f3-2307-4e0a-bc98-5c2cbfb260b6/toscaModel", |
| 1066 | "category": "Network L4+", |
| 1067 | "lifecycleState": "CERTIFIED", |
| 1068 | "lastUpdaterUserId": "cs0008", |
| 1069 | "distributionStatus": "DISTRIBUTED" |
| 1070 | } |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1071 | |
| 1072 | Listing should contain entry with our service name **vfw_cnf_cds_svc**. |
| 1073 | |
| 1074 | .. note:: Note that it's an example name, it depends on how your model is named during Service design in SDC and must be kept in sync with Postman variables. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1075 | |
| 1076 | - SO: |
| 1077 | |
| 1078 | SO Catalog database should have our service NFs defined now. |
| 1079 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1080 | :: |
| 1081 | |
| 1082 | Postman -> LCM -> [SO] Catalog DB Service xNFs |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1083 | |
| 1084 | :: |
| 1085 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1086 | { |
| 1087 | "serviceVnfs": [ |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 1088 | { |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1089 | "modelInfo": { |
| 1090 | "modelName": "vfw_cnf_cds_vsp", |
| 1091 | "modelUuid": "70edaca8-8c79-468a-aa76-8224cfe686d0", |
| 1092 | "modelInvariantUuid": "7901fc89-a94d-434a-8454-1e27b99dc0e2", |
| 1093 | "modelVersion": "1.0", |
| 1094 | "modelCustomizationUuid": "86dc8af4-aa17-4fc7-9b20-f12160d99718", |
| 1095 | "modelInstanceName": "vfw_cnf_cds_vsp 0" |
| 1096 | }, |
| 1097 | "toscaNodeType": "org.openecomp.resource.vf.VfwCnfCdsVsp", |
| 1098 | "nfFunction": null, |
| 1099 | "nfType": null, |
| 1100 | "nfRole": null, |
| 1101 | "nfNamingCode": null, |
| 1102 | "multiStageDesign": "false", |
| 1103 | "vnfcInstGroupOrder": null, |
| 1104 | "resourceInput": "TBD", |
| 1105 | "vfModules": [ |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 1106 | { |
| 1107 | "modelInfo": { |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1108 | "modelName": "VfwCnfCdsVsp..base_template..module-0", |
| 1109 | "modelUuid": "274f4bc9-7679-4767-b34d-1df51cdf2496", |
| 1110 | "modelInvariantUuid": "52842255-b7be-4a1c-ab3b-2bd3bd4a5423", |
| 1111 | "modelVersion": "1", |
| 1112 | "modelCustomizationUuid": "b27fad11-44da-4840-9256-7ed8a32fbe3e" |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 1113 | }, |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1114 | "isBase": true, |
| 1115 | "vfModuleLabel": "base_template", |
| 1116 | "initialCount": 1, |
| 1117 | "hasVolumeGroup": false |
| 1118 | }, |
| 1119 | { |
| 1120 | "modelInfo": { |
| 1121 | "modelName": "VfwCnfCdsVsp..vsn..module-1", |
| 1122 | "modelUuid": "0cbf558f-5a96-4555-b476-7df8163521aa", |
| 1123 | "modelInvariantUuid": "36f25e1b-199b-4de2-b656-c870d341cf0e", |
| 1124 | "modelVersion": "1", |
| 1125 | "modelCustomizationUuid": "4cac0584-c0d6-42a7-bdb3-29162792e07f" |
| 1126 | }, |
| 1127 | "isBase": false, |
| 1128 | "vfModuleLabel": "vsn", |
| 1129 | "initialCount": 0, |
| 1130 | "hasVolumeGroup": false |
| 1131 | }, |
| 1132 | { |
| 1133 | "modelInfo": { |
| 1134 | "modelName": "VfwCnfCdsVsp..vpkg..module-2", |
| 1135 | "modelUuid": "011b5f61-6524-4789-bd9a-44cfbf321463", |
| 1136 | "modelInvariantUuid": "4e2b9975-5214-48b8-861a-5701c09eedfa", |
| 1137 | "modelVersion": "1", |
| 1138 | "modelCustomizationUuid": "4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb" |
| 1139 | }, |
| 1140 | "isBase": false, |
| 1141 | "vfModuleLabel": "vpkg", |
| 1142 | "initialCount": 0, |
| 1143 | "hasVolumeGroup": false |
| 1144 | }, |
| 1145 | { |
| 1146 | "modelInfo": { |
| 1147 | "modelName": "VfwCnfCdsVsp..vfw..module-3", |
| 1148 | "modelUuid": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f", |
| 1149 | "modelInvariantUuid": "9ffda670-3d77-4f6c-a4ad-fb7a09f19817", |
| 1150 | "modelVersion": "1", |
| 1151 | "modelCustomizationUuid": "1e123e43-ba40-4c93-90d7-b9f27407ec03" |
| 1152 | }, |
| 1153 | "isBase": false, |
| 1154 | "vfModuleLabel": "vfw", |
| 1155 | "initialCount": 0, |
| 1156 | "hasVolumeGroup": false |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 1157 | } |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1158 | ], |
| 1159 | "groups": [] |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 1160 | } |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1161 | ] |
| 1162 | } |
| 1163 | |
| 1164 | .. note:: For **Native Helm** path both modelName will have prefix *helm_* i.e. *helm_vfw* and vfModuleLabel will have *helm_* keyword inside i.e. *VfwCnfCdsVsp..helm_vfw..module-3* |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1165 | |
| 1166 | - SDNC: |
| 1167 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1168 | SDNC should have it's database updated with *sdnc_* properties that were set during service modeling. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1169 | |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 1170 | .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_ |
| 1171 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1172 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1173 | :: |
| 1174 | |
| 1175 | kubectl -n onap exec onap-mariadb-galera-0 -it -- sh |
| 1176 | mysql -uroot -psecretpassword -D sdnctl |
| 1177 | MariaDB [sdnctl]> select sdnc_model_name, sdnc_model_version, sdnc_artifact_name from VF_MODEL WHERE customization_uuid = '86dc8af4-aa17-4fc7-9b20-f12160d99718'; |
| 1178 | +-----------------+--------------------+--------------------+ |
| 1179 | | sdnc_model_name | sdnc_model_version | sdnc_artifact_name | |
| 1180 | +-----------------+--------------------+--------------------+ |
| 1181 | | vFW_CNF_CDS | 7.0.0 | vnf | |
| 1182 | +-----------------+--------------------+--------------------+ |
| 1183 | 1 row in set (0.00 sec) |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1184 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1185 | |
| 1186 | .. note:: customization_uuid value is the modelCustomizationUuid of the VNF (serviceVnfs response in 2nd Postman call from SO Catalog DB) |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 1187 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1188 | - CDS: |
| 1189 | |
| 1190 | CDS should onboard CBA uploaded as part of VF. |
| 1191 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1192 | :: |
| 1193 | |
| 1194 | Postman -> Distribution Verification -> [CDS] List CBAs |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1195 | |
| 1196 | :: |
| 1197 | |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 1198 | [ |
| 1199 | { |
| 1200 | "blueprintModel": { |
| 1201 | "id": "c505e516-b35d-4181-b1e2-bcba361cfd0a", |
| 1202 | "artifactUUId": null, |
| 1203 | "artifactType": "SDNC_MODEL", |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1204 | "artifactVersion": "7.0.0", |
| 1205 | "artifactDescription": "Controller Blueprint for vFW_CNF_CDS:7.0.0", |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 1206 | "internalVersion": null, |
| 1207 | "createdDate": "2020-05-29T06:02:20.000Z", |
| 1208 | "artifactName": "vFW_CNF_CDS", |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1209 | "published": "N", |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 1210 | "updatedBy": "Samuli Silvius <s.silvius@partner.samsung.com>", |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1211 | "tags": "Samuli Silvius, Lukasz Rajewski, vFW_CNF_CDS" |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 1212 | } |
| 1213 | } |
| 1214 | ] |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1215 | |
| 1216 | The list should have the matching entries with SDNC database: |
| 1217 | |
| 1218 | - sdnc_model_name == artifactName |
| 1219 | - sdnc_model_version == artifactVersion |
| 1220 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1221 | You can also use Postman to download CBA for further verification but it's fully optional. |
| 1222 | |
| 1223 | :: |
| 1224 | |
| 1225 | Postman -> Distribution Verification -> [CDS] CBA Download |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1226 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1227 | - K8splugin: |
| 1228 | |
| 1229 | K8splugin should onboard 4 resource bundles related to helm resources: |
| 1230 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1231 | :: |
| 1232 | |
| 1233 | Postman -> Distribution Verification -> [K8splugin] List Resource Bundle Definitions |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1234 | |
| 1235 | :: |
| 1236 | |
Samuli Silvius | 7c41c16 | 2020-06-02 19:08:30 +0300 | [diff] [blame] | 1237 | [ |
| 1238 | { |
| 1239 | "rb-name": "52842255-b7be-4a1c-ab3b-2bd3bd4a5423", |
| 1240 | "rb-version": "274f4bc9-7679-4767-b34d-1df51cdf2496", |
| 1241 | "chart-name": "base_template", |
| 1242 | "description": "", |
| 1243 | "labels": { |
| 1244 | "vnf_customization_uuid": "b27fad11-44da-4840-9256-7ed8a32fbe3e" |
| 1245 | } |
| 1246 | }, |
| 1247 | { |
| 1248 | "rb-name": "36f25e1b-199b-4de2-b656-c870d341cf0e", |
| 1249 | "rb-version": "0cbf558f-5a96-4555-b476-7df8163521aa", |
| 1250 | "chart-name": "vsn", |
| 1251 | "description": "", |
| 1252 | "labels": { |
| 1253 | "vnf_customization_uuid": "4cac0584-c0d6-42a7-bdb3-29162792e07f" |
| 1254 | } |
| 1255 | }, |
| 1256 | { |
| 1257 | "rb-name": "4e2b9975-5214-48b8-861a-5701c09eedfa", |
| 1258 | "rb-version": "011b5f61-6524-4789-bd9a-44cfbf321463", |
| 1259 | "chart-name": "vpkg", |
| 1260 | "description": "", |
| 1261 | "labels": { |
| 1262 | "vnf_customization_uuid": "4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb" |
| 1263 | } |
| 1264 | }, |
| 1265 | { |
| 1266 | "rb-name": "9ffda670-3d77-4f6c-a4ad-fb7a09f19817", |
| 1267 | "rb-version": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f", |
| 1268 | "chart-name": "vfw", |
| 1269 | "description": "", |
| 1270 | "labels": { |
| 1271 | "vnf_customization_uuid": "1e123e43-ba40-4c93-90d7-b9f27407ec03" |
| 1272 | } |
| 1273 | } |
| 1274 | ] |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1275 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1276 | **<AUTOMATED>** |
| 1277 | |
| 1278 | Distribution is a part of the onboarding step and at this stage is performed |
| 1279 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1280 | 3-2 CNF Instantiation |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 1281 | ..................... |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1282 | |
| 1283 | 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. |
| 1284 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1285 | **<MANUAL>** |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1286 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1287 | 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: |
| 1288 | |
| 1289 | :: |
| 1290 | |
| 1291 | Postman -> LCM -> 1.[SDC] Catalog Service |
| 1292 | |
| 1293 | :: |
| 1294 | |
| 1295 | Postman -> LCM -> 2. [SO] Catalog DB Service xNFs |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1296 | |
| 1297 | Now actual instantiation can be triggered with: |
| 1298 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1299 | :: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1300 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1301 | Postman -> LCM -> 3. [SO] Self-Serve Service Assign & Activate |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1302 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1303 | **<AUTOMATED>** |
| 1304 | |
| 1305 | Required inputs for instantiation process are taken from the *config.py* file. |
| 1306 | :: |
| 1307 | |
| 1308 | python instantiation.py |
| 1309 | |
| 1310 | |
| 1311 | Finally, to follow the progress of instantiation request with SO's GET request: |
| 1312 | |
| 1313 | **<MANUAL>** |
| 1314 | |
| 1315 | :: |
| 1316 | |
| 1317 | Postman -> LCM -> 4. [SO] Infra Active Requests |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1318 | |
| 1319 | The successful reply payload in that query should start like this: |
| 1320 | |
| 1321 | :: |
| 1322 | |
| 1323 | { |
Konrad Bańka | 38af9cf | 2020-06-01 09:36:09 +0200 | [diff] [blame] | 1324 | "requestStatus": "COMPLETE", |
| 1325 | "statusMessage": "Macro-Service-createInstance request was executed correctly.", |
| 1326 | "flowStatus": "Successfully completed all Building Blocks", |
| 1327 | "progress": 100, |
| 1328 | "startTime": 1590996766000, |
| 1329 | "endTime": 1590996945000, |
| 1330 | "source": "Postman", |
| 1331 | "vnfId": "93b3350d-ed6f-413b-9cc5-a158c1676eb0", |
| 1332 | "tenantId": "aaaa", |
| 1333 | "requestBody": "**REDACTED FOR READABILITY**", |
| 1334 | "lastModifiedBy": "CamundaBPMN", |
| 1335 | "modifyTime": "2020-06-01T07:35:45.000+0000", |
| 1336 | "cloudRegion": "k8sregionfour", |
| 1337 | "serviceInstanceId": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72", |
| 1338 | "serviceInstanceName": "vfw-cnf-16", |
| 1339 | "requestScope": "service", |
| 1340 | "requestAction": "createInstance", |
| 1341 | "requestorId": "11c2ddb7-4659-4bf0-a685-a08dcbb5a099", |
| 1342 | "requestUrl": "http://infra:30277/onap/so/infra/serviceInstantiation/v7/serviceInstances", |
| 1343 | "tenantName": "k8stenant", |
| 1344 | "cloudApiRequests": [], |
| 1345 | "requestURI": "6a369c8e-d492-4ab5-a107-46804eeb7873", |
| 1346 | "_links": { |
| 1347 | "self": { |
| 1348 | "href": "http://infra:30277/infraActiveRequests/6a369c8e-d492-4ab5-a107-46804eeb7873" |
| 1349 | }, |
| 1350 | "infraActiveRequests": { |
| 1351 | "href": "http://infra:30277/infraActiveRequests/6a369c8e-d492-4ab5-a107-46804eeb7873" |
| 1352 | } |
| 1353 | } |
| 1354 | } |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1355 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1356 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1357 | Progress can be also followed also with `SO Monitoring`_ dashboard. |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 1358 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1359 | Service Instance Termination |
| 1360 | ++++++++++++++++++++++++++++ |
Lukasz Rajewski | c1b4bda | 2020-05-25 19:05:41 +0200 | [diff] [blame] | 1361 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1362 | Service instance can be terminated with the following postman call: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1363 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1364 | **<MANUAL>** |
| 1365 | :: |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1366 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1367 | Postman -> LCM -> 5. [SO] Service Delete |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1368 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1369 | **<AUTOMATED>** |
| 1370 | :: |
| 1371 | |
| 1372 | python delete.py |
| 1373 | |
| 1374 | .. note:: Automated service deletion mecvhanism takes information about the instantiated service instance from the *config.py* file and *SERVICE_INSTANCE_NAME* variable. If you modify this value before the deletion of existing service instance then you will loose opportunity to easy delete already created service instance. |
| 1375 | |
| 1376 | Second Service Instance Instantiation |
| 1377 | +++++++++++++++++++++++++++++++++++++ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1378 | |
| 1379 | To finally verify that all the work done within this demo, it should be possible to instantiate second vFW instance successfully. |
| 1380 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1381 | Trigger new instance createion. You can use previous call or a separate one that will utilize profile templating mechanism implemented in CBA: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1382 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1383 | **<MANUAL>** |
| 1384 | :: |
| 1385 | |
| 1386 | Postman -> LCM -> 6. [SO] Self-Serve Service Assign & Activate - Second |
| 1387 | |
| 1388 | **<AUTOMATED>** |
| 1389 | |
| 1390 | 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. |
| 1391 | :: |
| 1392 | |
| 1393 | python onboarding.py |
| 1394 | python instantiation.py |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1395 | |
| 1396 | 3-3 Results and Logs |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 1397 | .................... |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1398 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1399 | Now multiple instances of Kubernetes variant of vFW are running in target VIM (KUD deployment). |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1400 | |
| 1401 | .. figure:: files/vFW_CNF_CDS/vFW_Instance_In_Kubernetes.png |
| 1402 | :align: center |
| 1403 | |
| 1404 | vFW Instance In Kubernetes |
| 1405 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1406 | **<MANUAL>** |
| 1407 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1408 | 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. |
| 1409 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1410 | :: |
| 1411 | |
| 1412 | Postman -> Instantiation verification** |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1413 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1414 | Execute example Postman queries and check example section to see the valid results. |
| 1415 | |
| 1416 | ========================== ================= |
| 1417 | Verify Target Postman query |
| 1418 | -------------------------- ----------------- |
| 1419 | Service Instances in AAI **Postman -> Instantiation verification -> [AAI] List Service Instances** |
| 1420 | Service Instances in MDSAL **Postman -> Instantiation verification -> [SDNC] GR-API MD-SAL Services** |
| 1421 | K8S Instances in KUD **Postman -> Instantiation verification -> [K8splugin] List Instances** |
| 1422 | ========================== ================= |
| 1423 | |
| 1424 | .. note:: "[AAI] List vServers <Empty>" Request won't return any vserver info from AAI, as currently such information are not provided during instantiation process. |
| 1425 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1426 | |
| 1427 | Query also directly from VIM: |
| 1428 | |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1429 | :: |
| 1430 | |
| 1431 | # |
| 1432 | ubuntu@kud-host:~$ kubectl get pods,svc,networks,cm,network-attachment-definition,deployments |
| 1433 | NAME READY STATUS RESTARTS AGE |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 1434 | pod/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f-7cfb9949d9-8b5vg 1/1 Running 0 22s |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1435 | pod/vfw-19571429-4af4-49b3-af65-2eb1f97bba43-75cd7c6f76-4gqtz 1/1 Running 0 11m |
| 1436 | pod/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-f4485d485-pln8m 1/1 Running 0 11m |
| 1437 | pod/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-6f8cff54d-dvw4j 1/1 Running 0 32s |
| 1438 | pod/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-5879c56fd-q59l7 2/2 Running 0 11m |
| 1439 | pod/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-5889b7455-96j9d 2/2 Running 0 30s |
| 1440 | |
| 1441 | NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1442 | service/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-management-api NodePort 10.244.43.245 <none> 2831:30831/TCP 11m |
| 1443 | service/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-management-api NodePort 10.244.1.45 <none> 2831:31831/TCP 33s |
| 1444 | service/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-darkstat-ui NodePort 10.244.16.187 <none> 667:30667/TCP 11m |
| 1445 | service/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-darkstat-ui NodePort 10.244.20.229 <none> 667:31667/TCP 30s |
| 1446 | |
| 1447 | NAME AGE |
| 1448 | network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-management-network 40s |
| 1449 | network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-protected-network 40s |
| 1450 | network.k8s.plugin.opnfv.org/55118b80-8470-4c99-bfdf-d122cd412739-unprotected-network 40s |
| 1451 | network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-management-network 11m |
| 1452 | network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-protected-network 11m |
| 1453 | network.k8s.plugin.opnfv.org/567cecc3-9692-449e-877a-ff0b560736be-unprotected-network 11m |
| 1454 | |
| 1455 | NAME DATA AGE |
| 1456 | configmap/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f-configmap 6 22s |
| 1457 | configmap/vfw-19571429-4af4-49b3-af65-2eb1f97bba43-configmap 6 11m |
| 1458 | configmap/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e-configmap 6 11m |
| 1459 | configmap/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26-configmap 6 33s |
| 1460 | configmap/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14-configmap 2 11m |
| 1461 | configmap/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b-configmap 2 30s |
| 1462 | |
| 1463 | NAME AGE |
| 1464 | networkattachmentdefinition.k8s.cni.cncf.io/55118b80-8470-4c99-bfdf-d122cd412739-ovn-nat 40s |
| 1465 | networkattachmentdefinition.k8s.cni.cncf.io/567cecc3-9692-449e-877a-ff0b560736be-ovn-nat 11m |
| 1466 | |
| 1467 | NAME READY UP-TO-DATE AVAILABLE AGE |
Konrad Bańka | cc67f63 | 2020-03-12 12:09:13 +0100 | [diff] [blame] | 1468 | deployment.extensions/vfw-17f6f7d3-8424-4550-a188-cd777f0ab48f 1/1 1 1 22s |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1469 | deployment.extensions/vfw-19571429-4af4-49b3-af65-2eb1f97bba43 1/1 1 1 11m |
| 1470 | deployment.extensions/vpg-5ea0d3b0-9a0c-4e88-a2e2-ceb84810259e 1/1 1 1 11m |
| 1471 | deployment.extensions/vpg-8581bc79-8eef-487e-8ed1-a18c0d638b26 1/1 1 1 33s |
| 1472 | deployment.extensions/vsn-8e7ac4fc-2c31-4cf8-90c8-5074c5891c14 1/1 1 1 11m |
| 1473 | deployment.extensions/vsn-fdc9b4ba-c0e9-4efc-8009-f9414ae7dd7b 1/1 1 1 30s |
| 1474 | |
| 1475 | |
| 1476 | Component Logs From The Execution |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 1477 | +++++++++++++++++++++++++++++++++ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1478 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1479 | **<MANUAL>** |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1480 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1481 | All logs from the use case execution can be retrieved with following |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1482 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1483 | :: |
| 1484 | |
| 1485 | kubectl -n onap logs `kubectl -n onap get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep -m1 <COMPONENT_NAME>` -c <CONTAINER> |
| 1486 | |
| 1487 | where <COMPONENT_NAME> and <CONTAINER> should be replaced with following keywords respectively: |
| 1488 | |
| 1489 | - so-bpmn-infra, so-bpmn-infra |
| 1490 | - so-openstack-adapter, so-openstack-adapter |
| 1491 | - so-cnf-adapter, so-cnf-adapter |
| 1492 | - sdnc-0, sdnc |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1493 | |
| 1494 | From karaf.log all requests (payloads) to CDS can be found by searching following string: |
| 1495 | |
| 1496 | ``'Sending request below to url http://cds-blueprints-processor-http:8080/api/v1/execution-service/process'`` |
| 1497 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1498 | - cds-blueprints-processor, cds-blueprints-processor |
| 1499 | - multicloud-k8s, multicloud-k8s |
| 1500 | - network-name-gen, network-name-gen, |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1501 | |
mrichomme | e464389 | 2020-11-30 18:31:29 +0100 | [diff] [blame] | 1502 | **Debug log** |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1503 | |
| 1504 | In case more detailed logging is needed, here's instructions how to setup DEBUG logging for few components. |
| 1505 | |
| 1506 | - SDNC |
| 1507 | |
| 1508 | :: |
| 1509 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1510 | kubectl -n onap exec -it onap-sdnc-0 -c sdnc /opt/opendaylight/bin/client log:set DEBUG |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1511 | |
| 1512 | |
| 1513 | - CDS Blueprint Processor |
| 1514 | |
| 1515 | :: |
| 1516 | |
| 1517 | # Edit configmap |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1518 | kubectl -n onap edit configmap onap-cds-blueprints-processor-configmap |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1519 | |
| 1520 | # Edit logback.xml content change root logger level from info to debug. |
| 1521 | <root level="debug"> |
| 1522 | <appender-ref ref="STDOUT"/> |
| 1523 | </root> |
| 1524 | |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1525 | # Delete the Pods to make changes effective |
| 1526 | kubectl -n onap delete pods -l app=cds-blueprints-processor |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1527 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1528 | 3-4 Verification of the CNF Status |
| 1529 | .................................. |
| 1530 | |
| 1531 | **<MANUAL>** |
| 1532 | |
| 1533 | The Guilin introduces new API for verification of the status of instantiated resouces in k8s cluster. The API gives result similar to *kubectl describe* operation for all the resources created for particular *rb-definition*. Status API can be used to verify the k8s resources after instantiation but also can be used leveraged for synchronization of the information with external components, like AAI in the future. To use Status API call |
| 1534 | |
| 1535 | :: |
| 1536 | |
| 1537 | curl -i http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/{rb-instance-id}/status |
| 1538 | |
| 1539 | where {rb-instance-id} can be taken from the list of instances resolved the following call |
| 1540 | |
| 1541 | :: |
| 1542 | |
| 1543 | curl -i http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/ |
| 1544 | |
| 1545 | 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. |
| 1546 | |
Lukasz Rajewski | dd9bf99 | 2020-12-30 18:43:39 +0100 | [diff] [blame] | 1547 | 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. |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1548 | |
Lukasz Rajewski | dd9bf99 | 2020-12-30 18:43:39 +0100 | [diff] [blame] | 1549 | :download:`Full Status API Result <files/vFW_CNF_CDS/status-response.json>` |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1550 | |
| 1551 | :: |
| 1552 | |
| 1553 | { |
| 1554 | "request": { |
| 1555 | "rb-name": "vfw", |
| 1556 | "rb-version": "plugin_test", |
| 1557 | "profile-name": "test_profile", |
| 1558 | "release-name": "", |
| 1559 | "cloud-region": "kud", |
| 1560 | "labels": { |
| 1561 | "testCaseName": "plugin_fw.sh" |
| 1562 | }, |
| 1563 | "override-values": { |
| 1564 | "global.onapPrivateNetworkName": "onap-private-net-test" |
| 1565 | } |
| 1566 | }, |
| 1567 | "ready": false, |
Lukasz Rajewski | dd9bf99 | 2020-12-30 18:43:39 +0100 | [diff] [blame] | 1568 | "resourceCount": 1, |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1569 | "resourcesStatus": [ |
| 1570 | { |
| 1571 | "name": "sink-configmap", |
| 1572 | "GVK": { |
| 1573 | "Group": "", |
| 1574 | "Version": "v1", |
| 1575 | "Kind": "ConfigMap" |
| 1576 | }, |
| 1577 | "status": { |
| 1578 | "apiVersion": "v1", |
| 1579 | "data": { |
| 1580 | "protected_net_gw": "192.168.20.100", |
| 1581 | "protected_private_net_cidr": "192.168.10.0/24" |
| 1582 | }, |
| 1583 | "kind": "ConfigMap", |
| 1584 | "metadata": { |
| 1585 | "creationTimestamp": "2020-09-29T13:36:25Z", |
| 1586 | "labels": { |
| 1587 | "k8splugin.io/rb-instance-id": "practical_nobel" |
| 1588 | }, |
| 1589 | "name": "sink-configmap", |
| 1590 | "namespace": "plugin-tests-namespace", |
| 1591 | "resourceVersion": "10720771", |
| 1592 | "selfLink": "/api/v1/namespaces/plugin-tests-namespace/configmaps/sink-configmap", |
| 1593 | "uid": "46c8bec4-980c-455b-9eb0-fb84ac8cc450" |
| 1594 | } |
| 1595 | } |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1596 | } |
| 1597 | ] |
| 1598 | } |
| 1599 | |
Lukasz Rajewski | dd9bf99 | 2020-12-30 18:43:39 +0100 | [diff] [blame] | 1600 | .. note:: The example of how the Stauts API could be integrated into CDS can be found in the Frankfurt version of k8s profile upload mechanism `Frankfurt CBA Definition`_ (*profile-upload* TOSCA node template), implemented in inside of the Kotlin script `Frankfurt CBA Script`_ for profile upload. This method shows how to integrate mutlicloud-k8s API endpoint into Kotlin script executed by CDS. For more details please take a look into Definition file of 1.0.45 version of the CBA and also the kotlin script used there for uploading the profile. |
| 1601 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1602 | PART 4 - Future improvements needed |
Lukasz Rajewski | dd9bf99 | 2020-12-30 18:43:39 +0100 | [diff] [blame] | 1603 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1604 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1605 | Future development areas for this use case: |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1606 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1607 | - Automated smoke use case. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1608 | - Include Closed Loop part of the vFW demo. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1609 | - vFW service with Openstack VNF and Kubernetes CNF |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1610 | |
| 1611 | Future development areas for CNF support: |
| 1612 | |
| 1613 | - Validation of Helm package and extraction of override values in time of the package onboarding. |
| 1614 | - Post instantiation configuration with Day 2 configuration APIs of multicloud/k8S API. |
| 1615 | - Synchroinzation of information about CNF between AAI and K8s. |
| 1616 | - Validation of status and health of CNF. |
| 1617 | - Use multicloud/k8S API v2. |
| 1618 | |
| 1619 | Many features from the list above are covered by the Honolulu roadmap described in `REQ-458`_. |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1620 | |
| 1621 | |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1622 | .. _ONAP Deployment Guide: https://docs.onap.org/projects/onap-oom/en/guilin/oom_quickstart_guide.html |
| 1623 | .. _CDS Documentation: https://docs.onap.org/projects/onap-ccsdk-cds/en/guilin/index.html |
Konrad Bańka | c01b1fb | 2020-05-27 15:25:56 +0200 | [diff] [blame] | 1624 | .. _vLB use-case: https://wiki.onap.org/pages/viewpage.action?pageId=71838898 |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1625 | .. _vFW_CNF_CDS Model: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates?h=guilin |
| 1626 | .. _vFW_CNF_CDS Automation: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/automation?h=guilin |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1627 | .. _vFW CDS Dublin: https://wiki.onap.org/display/DW/vFW+CDS+Dublin |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1628 | .. _vFW CBA Model: https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/service-blueprint/vFW?h=elalto |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1629 | .. _vFW_Helm Model: https://git.onap.org/multicloud/k8s/tree/kud/demo/firewall?h=elalto |
| 1630 | .. _vFW_NextGen: https://git.onap.org/demo/tree/heat/vFW_NextGen?h=elalto |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1631 | .. _vFW EDGEX K8S: https://docs.onap.org/en/elalto/submodules/integration.git/docs/docs_vfw_edgex_k8s.html |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1632 | .. _vFW EDGEX K8S In ONAP Wiki: https://wiki.onap.org/display/DW/Deploying+vFw+and+EdgeXFoundry+Services+on+Kubernets+Cluster+with+ONAP |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1633 | .. _KUD github: https://github.com/onap/multicloud-k8s/tree/master/kud/hosting_providers/baremetal |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1634 | .. _KUD in Wiki: https://wiki.onap.org/display/DW/Kubernetes+Baremetal+deployment+setup+instructions |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1635 | .. _Multicloud k8s gerrit: https://gerrit.onap.org/r/q/status:open+project:+multicloud/k8s |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1636 | .. _KUD subproject in github: https://github.com/onap/multicloud-k8s/tree/master/kud |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1637 | .. _Frankfurt CBA Definition: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba/Definitions/vFW_CNF_CDS.json?h=frankfurt |
| 1638 | .. _Frankfurt CBA Script: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba/Scripts/kotlin/KotlinK8sProfileUpload.kt?h=frankfurt |
| 1639 | .. _SO-3403: https://jira.onap.org/browse/SO-3403 |
| 1640 | .. _SO-3404: https://jira.onap.org/browse/SO-3404 |
| 1641 | .. _REQ-182: https://jira.onap.org/browse/REQ-182 |
| 1642 | .. _REQ-341: https://jira.onap.org/browse/REQ-341 |
| 1643 | .. _REQ-458: https://jira.onap.org/browse/REQ-458 |
| 1644 | .. _Python SDK: https://docs.onap.org/projects/onap-integration/en/guilin/integration-tooling.html?highlight=python-sdk#python-onapsdk |
Samuli Silvius | a58b0b4 | 2020-02-18 10:00:47 +0200 | [diff] [blame] | 1645 | .. _KUD Jenkins ci/cd verification: https://jenkins.onap.org/job/multicloud-k8s-master-kud-deployment-verify-shell/ |
Lukasz Rajewski | ee41f3b | 2020-12-22 00:30:02 +0100 | [diff] [blame] | 1646 | .. _K8s cloud site config: https://docs.onap.org/en/guilin/guides/onap-operator/cloud_site/k8s/index.html |
| 1647 | .. _SO Monitoring: https://docs.onap.org/projects/onap-so/en/guilin/developer_info/Working_with_so_monitoring.html |
| 1648 | .. _Data Dictionary: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba-dd.json?h=guilin |
| 1649 | .. _Helm Healer: https://git.onap.org/oom/offline-installer/tree/tools/helm-healer.sh?h=frankfurt |
mrichomme | a958b98 | 2020-04-13 18:46:35 +0200 | [diff] [blame] | 1650 | .. _CDS UAT Testing: https://wiki.onap.org/display/DW/Modeling+Concepts |
mrichomme | 20a4dbd | 2020-07-08 17:52:13 +0200 | [diff] [blame] | 1651 | .. _infra_workload: https://docs.onap.org/projects/onap-multicloud-framework/en/latest/specs/multicloud_infra_workload.html?highlight=multicloud |