Proposal on SDC Client Design

some ideas about how to implmenent it useable for
both k8s and openstack/windRiver
. implement it as an artifact management include a
sdc client and add subplugin configuration
. align with Eric's proposal on SO-to-Multicloud API
enhancements
. add and update the example about downloaded files layout

Change-Id: Ia5a22482fa3c1c11ba1195fa7b8be4dcd67fe662
Issue-ID: MULTICLOUD-436
Signed-off-by: liboNet <libo.zhu@intel.com>

2 files changed, 192 insertions, 1 deletions

diff --git a/docs/specs/multicloud-SDC-Client-design.rst b/docs/specs/multicloud-SDC-Client-design.rst
new file mode 100644
index 0000000..be7d5e4
--- /dev/null
+++ b/docs/specs/multicloud-SDC-Client-design.rst
@@ -0,0 +1,179 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+===============================================================
+MultiCloud SDC Client Design for k8s and windRiver/Openstack
+===============================================================
+To support  multicloud plugin access the concerned artifacts, do prepration
+if necessnary, need registering the artifact management as a sdc client and
+use shared folder method so that enable user to freely access the artifacts.
+by configuring such client, user could decide what artifact needs download,
+what's the actions to do for the downloaded artifact etc.
+
+after OOM deploy such artifact management, the plugins could access all the
+downloaded artifacts by shared folder method if necessary.
+
+Problems Statement
+==================
+the SDC artifacts is part of CSAR, which is downloaded by SDC client.
+Currently in Casablanca release, some components: SO, Policy, AAI
+register as a SDC client, could download the concerned artifacts based
+on the Notification from SDC
+
+There are two things need support in Dublin release in MultiCloud side:
+1. support k8s. download k8s related artifacts from SDC, and do specified
+postprocessing during design-time, artifacts could be used/got during
+instantiation time
+
+2. support WindRiver/OpenStack plugin to download HEAT/HEAT_ENV related
+artifacts from SDC and change the currently API interface between SO and
+MutliCloud to transfer the indication of these artifacts instead of  the
+whole content of HEAT/HEAT_ENV. then MutliCloud use the indications from SO,
+to find the downloaded artifacts during instantiation time
+
+
+Proposed framework
+=========================================================
+
+
+SDC Reception Handler<----> Reception Handler<-->Artifact Management<---->Plugin Handler<---->multicloudPost
+refer to `SDC Service Architecture
+<https://wiki.onap.org/display/DW/Policy+Platform+-+SDC+Service+Distribution+Software+Architecture>`_
+
+Proposed alternative Solutions
+==========================================================
+There would be a artifact management comopnent, which will do below steps once get the
+notification from SDC during design time.
+
+1.mandatory step to download concerned artifacts from SDC directly store
+it locally by specified rule of layout as under "vf-module-model-customization-id" directory
+the related heat and heat_env file will be put with the name of own uuid, an addtional
+metadata.json file will be there which includes details description about vf module.
+
+2.check if subplugin is configurated in the configuration file
+
+a. configurated: it will invoke the pre-configurated Post API once the concerned
+artifact has been downloaded. current k8s plugin need leverage such function
+
+b. not configurated: then its plugin's duty to access the artifacts by shared folder
+method and parse the metadata information.
+
+
+leverage the Policy distribution framework by doing below change:
+
+1.modify the SDC Reception Handler to add its support to download resource level artifacts
+like HEAT/HEAT_ENV and K8S_CLOUD.
+
+2.change the SDC client configuration interface by storing the artifact into Database
+
+3.add a k8s into plugin Handler of the framework which will do the post API
+on the downloaded artifact which will be put into the locally
+
+**With respect to k8s artifact**:
+
+the required input data format for k8s API, suppose resource level too, like VnfId, UUID
+
+**With respect to openStack/windRiver artifact**:
+
+the requried input data format for openStack/windRiver API for resource level, it will use
+"vf-module-model-customization-id" as the key to directive plugins
+
+Layout example
+==============
+vfmodule-meta.json content
+--------------------------
+::
+
+ [
+  {
+    "vfModuleModelName": "VcpevsVgw0116a..base_vcpe_vgw..module-0",
+    "vfModuleModelInvariantUUID": "718c9883-8fd6-463a-b00d-0c696e0ab475",
+    "vfModuleModelVersion": "1",
+    "vfModuleModelUUID": "585fce63-101f-49f2-95d6-c53423baa48a",
+    "vfModuleModelCustomizationUUID": "4668b783-2dba-444f-b3d8-a508f0d0c0f2",
+    "isBase": true,
+    "artifacts": [
+      "0a38b7ef-93b9-4d48-856d-efb56d53aab8",
+      "4d4a37ef-6a1f-4cb2-b3c9-b380a5940431"
+    ],
+    "properties": {
+      "min_vf_module_instances": "1",
+      "vf_module_label": "base_vcpe_vgw",
+      "max_vf_module_instances": "1",
+      "vfc_list": "",
+      "vf_module_description": "",
+      "vf_module_type": "Base",
+      "availability_zone_count": "",
+      "volume_group": "false",
+      "initial_count": "1"
+    }
+  }
+ ]
+
+service-meta.json content
+-------------------------
+::
+
+ {
+  "artifacts":
+   [
+    {
+     "artifactName": "base_template.env",
+     "artifactType": "HEAT_ENV",
+     "artifactURL":
+     "/sdc/v1/catalog/services/ead658ee-f224-4e49-9f3f-8b4c49ed18dc/resourceInstances/vfwnextgen0/artifacts/0a38b7ef-93b9-4d48-856d-efb56d53aab8",
+     "artifactDescription": "Auto-generated HEAT Environment deployment artifact",
+     "artifactChecksum": "YzdmZDQxMjdiYjBmZDU1YWQ5YTMxZGExNWM4MjRlYzQ=",
+     "artifactUUID": "0a38b7ef-93b9-4d48-856d-efb56d53aab8",
+     "artifactVersion": "2",
+     "generatedFromUUID": "20b803f5-b137-45aa-9196-6b79f9b9f527.heat4",
+     "artifactLabel": "heat4env",
+     "artifactGroupType": "DEPLOYMENT"
+     },
+     {
+     "artifactName": "base_template.yaml",
+     "artifactType": "HEAT",
+     "artifactURL":
+     "/sdc/v1/catalog/services/ead658ee-f224-4e49-9f3f-8b4c49ed18dc/resourceInstances/vfwnextgen0/artifacts/4d4a37ef-6a1f-4cb2-b3c9-b380a5940431",
+     "artifactDescription": "created from csar",
+     "artifactTimeout": 60,
+     "artifactChecksum": "MGMwNzkwNmZkODExZmFkMTgwMTljMGIwNWMxOWZlODY=",
+     "artifactUUID": "4d4a37ef-6a1f-4cb2-b3c9-b380a5940431",
+     "artifactVersion": "2",
+     "artifactLabel": "heat4",
+     "artifactGroupType": "DEPLOYMENT"
+     }
+   ]
+  }
+
+the directory layout
+--------------------
+under 4668b783-2dba-444f-b3d8-a508f0d0c0f2 dir, there would be 4 files:
+::
+
+    base_template.yaml it's a HEAT artifact
+    base_template.env  it's a HEAT_ENV artifact
+    vfmodule-meta.json
+    service-meta.json includes all artifacts details info of the artifact_list
+
+
+Dependency
+==============
+1. SDC support:
+   SDC-2041 SDC supports K8S plugin to expose APIs to add/delete cloud specific artifacts
+   SDC-2045 create User and Password for MultiCloud component to access secure API
+   A CSAR example including k8s artifact
+2. SO support:
+   modify the current interface between SO and Mutlicloud
+3. MutliCloud support:
+   implement the invoke logic  for the downloaded artifact conconered by k8s, clarify all the
+   necessary information needed.
+4. OOM support:
+   need a configuration for necessary pods during deployment
+   need to define how to the common setting instead of hard-code
+
+Test Use Cases
+==============
+1. For k8s. the artifacts are Helm chart. need a k8s lab env for validation. need to clarify if there is some connection
+between the VNFs, like using VirtualLink or just a service which is a simple wrap of one VNF
+
+2. For OpenStack/WindRiver, use vFW test case with HEAT/HEAT_ENV artifacts.
diff --git a/docs/specs/multicloud_infra_workload.rst b/docs/specs/multicloud_infra_workload.rst
index 6da49ae..57b3f7c 100644
--- a/docs/specs/multicloud_infra_workload.rst
+++ b/docs/specs/multicloud_infra_workload.rst
@@ -19,7 +19,8 @@ Currently HPA flavors are returned by OOF to SO and SO copies these flavors in
 the Heat template before sending the Heat template to Multicloud. In Casablanca
 instead of SO making changes in the Heat template the flavor information will be
 provided to Multicloud and Multicloud will pass this as parameters to HEAT
-command line.
+command line. In Dublin, instead of SO transferring the content of HEAT and HEAT_ENV
+to Multicloud, Mutlicloud will download these information/artifacts.
 For further detailed design, please refer to https://wiki.onap.org/display/DW/SO+Casablanca+HPA+Design
 
 
@@ -65,12 +66,23 @@ Request Body:
   {
      "generic-vnf-id":"<generic-vnf-id>",
      "vf-module-id":"<vf-module-id>",
+     "vf-module-model-invariant-id":"<uuid>",
+     "vf-module-model-version-id":"<uuid>",
+     "vf-module-model-customization-id":"<uuid>",
      "oof_directives":{},
      "sdnc_directives":{},
+     "user_directives":{},
      "template_type":"<heat/tosca/etc.>",
      "template_data":{}
   }
 
+ The 'vf-module-model-"*"-id’s will be used by the Multicloud plugin to retrieve the associated cloud artifacts.
+ The 'oof_directives' is to convey oof’s input to multicloud.
+ The 'sdnc_directives' for SDNC input to MultiCloud.
+ The 'user_directives' is the parameter to convey input from VID portal to mutlicloud.
+ They are all about how to populate data to template parameters.
+ The precedence of the three directives are user_directives and oof_directives the sdnc_directives.
+
 oof_directives:
 :::::::::::::::
 ::