...
For onboarding instructions please refer to steps 4-9 from the document here.
Distribute the CSAR
On onboarding, a service gets stored in SDC and as a final action, it is distributed to SO and other services. When distribution happens it takes tar.gz file and uploads to k8s plugin.
Steps for installing KUD Cloud
...
PUT https://{{AAI1_PUB_IP}}:{{AAI1_PUB_PORT}}/aai/v16/cloud-infrastructure/cloud-regions/cloud-region/k8scloudowner4/k8sregionfour/tenants/tenant/6bbd2981b210461dbc8fe846df1a7808?resource-version=1559345527327 |
...
Onboard a service it gets stored in SDC final action is distributed. SO and other services are notified sdc listener in the multicloud sidecar. When distribution happens it takes tar.gz file and uploads to k8s plugin.
Create Profile Manually
K8s-plugin artifacts start in the form of Definitions. These are nothing but Helm Charts wrapped with some metadata about the chart itself. Once the Definitions are created, we are ready to create some profiles so that we can customize that definition and instantiate it in Kubernetes.
(NOTE: Refer this link for complete API lists and documentation: MultiCloud K8s-Plugin-service API)
A profile contains the following:
- manifest.yaml
- Contains the details for the profile and everything contained within
- A HELM values override yaml file.
- It can have any name as long as it matches the corresponding entry in the manifest.yaml
- Any number of files organized in a folder structure
- All these files should have a corresponding entry in manifest.yaml file
Creating a Profile Artifact
...
The manifest file contains the following
...
---
version: v1
type:
values: "values_override.yaml"
configresource:
- filepath: testfol/subdir/deployment.yaml
chartpath: vault-consul-dev/templates/deployment.yaml
Note: values: "values_override.yaml" can be empty file if you are creating a dummy profile
Note: A dummy profile does not need any customization. The following is optional in the manifest file.
...
configresource:
- filepath: testfol/subdir/deployment.yaml
chartpath: vault-consul-dev/templates/deployment.yaml
We need to read the name of the Definition which was created while distribution of the service from SDC.
Command to read the Definition name and its version
On the ONAP K8s Rancher host execute following statement
...
kubectl logs -n onap `kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep multicloud-k8s | head -1` -c multicloud-k8s
From the output read the name of the definition which is "rb-name" and "rb-version" respectively
...
127.0.0.1 - - [15/Jul/2019:07:56:21 +0000] "POST /v1/rb/definition/test-rbdef/1/content HTTP/1.1"
Command to read (GET) Definition
With this information, we are ready to upload the profile with the following JSON data
...
{
"rb-name": "test-rbdef",
"rb-version": "1",
"profile-name": "p1",
"release-name": "r1", //If release-name is not provided, profile-name will be used
"namespace": "testnamespace1",
"kubernetes-version": "1.13.5"
}
4. Addition of Cloud Region to SO Catalog DB
See starting around 4:45 of the video - https://wiki.onap.org/download/attachments/64006768/vfwk8s_cloud_registration_720.mp4
Additional SO Configuration
There is a configuration needed for SO – it is described here in the docs (in step 4): https://onap.readthedocs.io/en/latest/submodules/integration.git/docs/docs_vfwHPA.html#docs-vfw-hpa
But also replicated below for convenience:
Modify the SO bpmn configmap to change the SO vnf adapter endpoint to v2
oom-rancher# kubectl -n onap edit configmap dev-so-so-bpmn-infra-app-configmap
- vnf:
endpoint: http://so-openstack-adapter.onap:8087/services/VnfAdapter
rest:
endpoint: http://so-openstack-adapter.onap:8087/services/rest/v1/vnfs
+ vnf:
endpoint: http://so-openstack-adapter.onap:8087/services/VnfAdapter
rest:
endpoint: http://so-openstack-adapter.onap:8087/services/rest/v2/vnfs
Then delete the bpmn pod
oom-rancher# kubectl delete <pod-name> -n onap
Create Profile Manually
K8s-plugin artifacts start in the form of Definitions. These are nothing but Helm Charts wrapped with some metadata about the chart itself. Once the Definitions are created, we are ready to create some profiles so that we can customize that definition and instantiate it in Kubernetes.
(NOTE: Refer this link for complete API lists and documentation: MultiCloud K8s-Plugin-service API)
A profile contains the following:
- manifest.yaml
- Contains the details for the profile and everything contained within
- A HELM values override yaml file.
- It can have any name as long as it matches the corresponding entry in the manifest.yaml
- Any number of files organized in a folder structure
- All these files should have a corresponding entry in manifest.yaml file
Creating a Profile Artifact
> cd multicloud-k8s/kud/tests/vnfs/testrb/helm/profile |
The manifest file contains the following
--- |
Note: values: "values_override.yaml" can be empty file if you are creating a dummy profile
Note: A dummy profile does not need any customization. The following is optional in the manifest file.
configresource: |
We need to read the name of the Definition which was created while distribution of the service from SDC.
Command to read the Definition name and its version
On the ONAP K8s Rancher host execute following statement
kubectl logs -n onap `kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep multicloud-k8s | head -1` -c multicloud-k8s |
From the output read the name of the definition which is "rb-name" and "rb-version" respectively
127.0.0.1 - - [15/Jul/2019:07:56:21 +0000] "POST /v1/ |
Command to create (POST) Profile
curl -i -d @create_rbprofile.json -X POST http://MSB_NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition/test-rbdef/1/profilecontent HTTP/1.1" |
Command to
...
read (GET) Definition
With this information, we are ready to upload the profile with the following JSON data
{ |
Command to create (POST) Profile
curl -i -d @create_rbprofile.json -X POST |
...
curl -i --data-binary @profile.tar.gz -X POST http://MSB_NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition/test-rbdef/1/profile/p1/content
Command to GET Profiles
# Get all Profiles |
Command to DELETE UPLOAD artifact for Profile
curl -i -X DELETE -data-binary @profile.tar.gz -X POST http://MSB_NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition/test-rbdef/1/profile/p1 |
Instantiation
Instantiation is done by SO. SO then talks to Multi Cloud-broker via MSB and that in turn looks up the cloud region in AAI to find the endpoint. If k8sregion one is registered with AAI and SO makes a call with that, then the broker will know that it needs to talk to k8s-plugin based on the type of the registration.
Instantiate the created Profile via the following REST API
Using the following JSON:
...
{
"cloud-region": "kud",
"profile-name": "p1",
"rb-name":"test-rbdef",
"rb-version":"1",
"labels": {
}
}
Command to GET Profiles
# Get all Profiles |
Command to DELETE Profile
curl -i -X DELETE |
NOTE: Make sure that the namespace is already created before instantiation.
Instantiate the profile with the ID provided above
Command to Instantiate a Profile
curl -d @create_rbinstance.json http://MSB_NODE_IP:30280/api/multicloud-k8s/v1/v1/instance |
The command returns the following JSON
...
{
"id": "ZKMTSaxv",
"rb-name": "mongo",
"rb-version": "1",
"profile-name": "profile1",
"cloud-region": "kud",
"namespace": "testns",
"resources": [
{
"GVK": {
"Group": "",
"Version": "v1",
"Kind": "Service"
},
"Name": "mongo"
},
{
"GVK": {
"Group": "",
"Version": "v1",
"Kind": "Service"
},
"Name": "mongo-read"
},
{
"GVK": {
"Group": "apps",
"Version": "v1beta1",
"Kind": "StatefulSet"
},
"Name": "profile1-mongo"
}
]
}
Instantiation
Instantiation is done by SO. SO then talks to Multi Cloud-broker via MSB and that in turn looks up the cloud region in AAI to find the endpoint. If k8sregion one is registered with AAI and SO makes a call with that, then the broker will know that it needs to talk to k8s-plugin based on the type of the registration.
This video shows the whole sequence of instantiation using VID:
https://wiki.onap.org/download/attachments/64006768/vfwk8s_deploy_delete_720.mp4
Create User parameters
In the VID user parameters are created in the following format during vfModule creation:
Known Issues:
- Use the vFw Helm chart from the Master branch - (https://github.com/onap/multicloud-k8s/tree/master/kud/demo/firewall)
- Artifact broker version issue (Libo to update this section)
- Recommended way tar the resource bundle image is tar.gz. helm package is not supported in Dublin.
- In Dublin Get all Definitions is not supported in K8s Plugin API's. Bug is filed for this.
Commands for instantiation using K8s API:
These commands can be used to interact directly with K8s Plugin with SO.
Command to Instantiate a Profile
Delete Instantiated Kubernetes resources
The id field from the returned JSON can be used to DELETE the resources created in the previous step. This executes a Delete operation using the Kubernetes API.
GET Instantiated Kubernetes resources
The id field from the returned JSON can be used to GET the resources created in the previous step. This executes a get operation using the Kubernetes API.
curl -d @create_rbinstance.json |
...
Delete Instantiated Kubernetes resources
The id field from the returned JSON can be used to DELETE the resources created in the previous step. This executes a Delete operation using the Kubernetes API.
GET Instantiated Kubernetes resources
The id field from the returned JSON can be used to GET the resources created in the previous step. This executes a get operation using the Kubernetes API.
We need to create parameters that ultimately get translated as:
"attributes": [
{
"attribute_name": "definition-name",
"attribute_value": "edgex"
},
{
"attribute_name": "definition-version",
"attribute_value": "v1"
},
{
"attribute_name": "profile-name",
"attribute_value": "profile1"
}
]
}