MultiCloud K8s-Plugin-service API
- Former user (Deleted)
- Lukasz Rajewski
- Former user (Deleted)
Definitions API
K8splugin artifacts start in the form of Definitions. These are nothing but Helm Charts wrapped with some metadata about the chart itself.
The package can be generated using the helm package command.
A Sample Helm Chart can be viewed in this patch: https://gerrit.onap.org/r/#/c/76371/
The contents for that chart are below.
> cd vagrant/tests/vnfs/testrb/helm > find vault-consul-dev vault-consul-dev vault-consul-dev/Chart.yaml vault-consul-dev/values.yaml vault-consul-dev/templates vault-consul-dev/templates/service.yaml vault-consul-dev/templates/deployment.yaml vault-consul-dev/charts vault-consul-dev/charts/common/values.yaml vault-consul-dev/charts/common/templates/_service.tpl vault-consul-dev/charts/common/templates/_repository.tpl vault-consul-dev/charts/common/templates/_name.tpl vault-consul-dev/charts/common/templates/_namespace.tpl vault-consul-dev/charts/common/templates vault-consul-dev/charts/common/Chart.yaml vault-consul-dev/charts/common #Create a tar.gz for upload > tar -cf vault-consul-dev.tar vault-consul-dev > gzip vault-consul-dev.tar
Managing Definitions
The following curl commands can be used to upload a definition and the helm chart for that definition.
With the following JSON content
{
"rb-name": "test-rbdef",
"rb-version": "v1",
"chart-name": "vault-consul-dev", //optional field. chart-name will be detected if this is not provided.
"description": "testing resource bundle definition api",
"labels": {
}
}
Command to create (POST) Definition:
curl -i -d @create_rbdefinition.json -X POST http://NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition
Command to UPLOAD artifact for Definition Created:
curl -i --data-binary @vault-consul-dev.tar.gz -X POST http://NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition/test-rbdef/v1/content
Command to GET Definitions:
# Get all Definitions curl -i http://NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition # Get one Definition curl -i http://NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition/test-rbdef/v1
Command to DELETE Definitions:
#Delete all versions of definition curl -i -X DELETE http://NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition/test-rbdef #Delete a particular version of definition curl -i -X DELETE http://NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition/test-rbdef/v1
Profiles API
Once the Definitions are created, we are ready to create some profiles so that we can customize that definition and instantiate it in Kubernetes.
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
Sample Profile is described in the above patch
Create the profile artifact
> cd vagrant/tests/vnfs/testrb/helm/profile > find . manifest.yaml override_values.yaml testfol testfol/subdir testfol/subdir/deployment.yaml #Create profile tar.gz > cd profile > tar -cf profile.tar * > gzip profile.tar > mv profile.tar.gz ../
Manifest file contains following
---
version: v1
type:
values: "values_override.yaml"
configresource:
- filepath: testfol/subdir/deployment.yaml
chartpath: vault-consul-dev/templates/deployment.yaml
With this information, we are ready to upload the profile with the following JSON data
{
"rb-name": "test-rbdef",
"rb-version": "v1",
"profile-name": "p1",
"release-name": "r1", //If release-name is not provided, profile-name will be used
"namespace": "testnamespace1",
"kubernetes-version": "1.12.3"
}
Command to create (POST) Profile
#Replace NODE_IP:30280/api/multicloud-k8s/v1 with NODE_PORT:30280/api/multicloud-k8s/v1 if you are connec curl -i -d @create_rbprofile.json -X POST http://NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition/test-rbdef/v1/profile
Command to UPLOAD artifact for Profile
curl -i --data-binary @profile.tar.gz -X POST http://NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition/test-rbdef/v1/profile/p1/content
Command to GET Profiles
# Get all Profiles curl -i http://NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition/test-rbdef/v1/profile # Get one Profile curl -i http://NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition/test-rbdef/v1/profile/p1
Command to DELETE Profile
curl -i -X DELETE http://NODE_IP:30280/api/multicloud-k8s/v1/v1/rb/definition/test-rbdef/v1/profile/p1
Instantiation API
Instantiate the created Profile via the following REST api
Using the following JSON:
{
"cloud-region": "krd",
"profile-name": "p1",
"release-name": "release-x",
"rb-name":"test-rbdef",
"rb-version":"v1",
"override-values": {
"optionalDictOfParameters": "andTheirValues, like",
"global.name": "dummy-name"
},
"labels": {
"optionalLabelForInternalK8spluginInstancesMetadata": "dummy-value"
}
}
Please note that both labels, override-parameters and release-name fields are optional.
When not provided, "release-name" will be reused from profile definition, however user should intend to provide own release name during instantiation if he wants to reuse same profile for multiple instances.
Instantiate the profile with the ID provided above
curl -d @create_rbinstance.json http://NODE_IP:30280/api/multicloud-k8s/v1/v1/instance
This command returns the following JSON:
{
"id": "ID_GENERATED_BY_K8SPLUGIN",
"namespace": "NAMESPACE_WHERE_INSTANCE_HAS_BEEN_DEPLOYED_AS_DERIVED_FROM_PROFILE",
"release-name": "RELEASE_NAME_AS_COMPUTED_BASED_ON_INSTANTIATION_REQUEST_AND_PROFILE_DEFAULT",
"request": {
"rb-name": "test-rbdef",
"rb-version": "v1",
"profile-name": "p1",
"release-name": "release-x",
"cloud-region": "krd",
"override-values": {
"optionalDictOfParameters": "andTheirValues, like",
"global.name": "dummy-name"
},
"labels": {
"optionalLabelForInternalK8spluginInstancesMetadata": "dummy-value"
},
}
"resources": [
{
"GVK": {
"Group": "",
"Kind": "ConfigMap",
"Version": "v1"
},
"Name": "test-cm"
},
{
"GVK": {
"Group": "",
"Kind": "Service",
"Version": "v1"
},
"Name": "test-svc"
},
{
"GVK": {
"Group": "apps",
"Kind": "Deployment",
"Version": "v1"
},
"Name": "test-dep"
}
]
}
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.
curl -X DELETE http://NODE_IP:30280/api/multicloud-k8s/v1/v1/instance/ZKMTSaxv
GET Instantiated Kubernetes resources
The id field from the returned JSON can be used to GET the resources created in the previous step
curl -X GET http://NODE_IP:30280/api/multicloud-k8s/v1/v1/instance/ZKMTSaxv
Output of this call conforms to the same schema and contains (currently) same information as instantiation response (described above)
LIST all Instantiated Kubernetes resources
The following API can be used to GET all the instances we have created.
curl -X GET http://NODE_IP:30280/api/multicloud-k8s/v1/v1/instance
Status API
Status API allows for monitoring/querying for instantiated CNFs status. It allows checking both design-time (eg. image name, node port) or runtime (eg. container statuses, deployment readiness) capabilities of resources managed within k8splugin instances.
GET Instantiated Kubernetes resource's status
curl -X GET http://NODE_IP:30280/api/multicloud-k8s/v1/v1/instance/{instanceID}/status
Example response:
Configuration API
Day 2 Configurations for applications are applied using K8S kinds (typically CRDs) implemented by application specific operators. For a given application, type of configuration is similar (but not the values), therefore configuration templates are created by applications. These templates are for each application and are expected to be created even before Day 2 configuration is applied. Once the templates are created, configuration can be applied by choosing the right template. Day 2 configuration is applied by users as and when new configuration is required. As a user, he/she should select the template and supply values to apply new configuration.
Configuration Template API
Command to POST (create) Template:
|
With the following JSON content (create_config_template.json )
1 |
|
Command to UPLOAD Template:
|
Command to GET Templates:
|
Command to DELETE Templates:
|
Example
Example Contents of Tar File
|
Configuration Values API
In Day 2 apply configuration API each instance of configuration is identified by rb_name, rb_version and profile_name. The body of the API contains set of parameter and value list.
Command to POST (create) Configuration Values
|
With the following JSON content (values.json )
|
This command returns the following JSON which contains config-version id.
|
Command to GET Configuration Values
|
Command to DELETE Configuration Values
|
Command to PUT (Modify) Configuration Values
|
With the following JSON content (values.json )
|
This command returns the following JSON which contains config-version.
|
Command to TAG configuration Values
This will add the tag name to the current config version
|
With the following JSON content (values.json )
|
Command to ROLLBACK configuration Values
Rollbacks configuration to a config version or a tag.
|
With the following JSON content (values.json )
|
Reachability/Connectivity Info API
API to support Reachability for Kubernetes Cloud
Command to POST Connectivity Info
{
“cloud-region” : “<name>”, // Must be unique across
“cloud-owner” : “<owner>”,
“other-connectivity-list” : {
//Extendible list of name value pairs
“connectivity-records” : [
{
“connectivity-record-name” : “<name>”, // example: OVN
“FQDN-or-ip” : “<fqdn>”,
“ca-cert-to-verify-server” : “<contents of CA certificate to validate the OVN server>”,
“ssl-initiator” : “<true/false”>,
“user-name”: “<user name>”, //valid if ssl-initator is false
“password” : “<password>”, // valid if ssl-initiator is false
“private-key” : “<contents of private key in PEM>”, // valid if ssl-initiator is true
“cert-to-present” : “<contents of certificate to present to server>” , //valid if ssl-initiator is true
},
]
}
}
This is a multipart upload and here is how you do the POST for this.
|
Command to GET Connectivity Info
|
Command to DELETE Connectivity Info
|
Command to UPDATE/PUT Connectivity Info
|
Infrastructure workload LCM API
APIs defined here conform to API defined by main multicloud broker service: https://docs.onap.org/en/dublin/submodules/multicloud/framework.git/docs/MultiCloud-APIv1-Specification.html#infrastructure-workload-lcm
Example request toward "Instantiate" API can look as follows:
Please note that following attributes from *_directives have special meaning: "k8s-rb-profile-name" (mandatory) and "k8s-rb-instance-release-name" (optional). They correspond to "profile-name" and "release-name" parameters from instance API.