MultiCloud K8s-Plugin-service API's

Definitions API's

K8splugin artifacts start in the form of Definitions. These are nothing but Helm Charts wrapped with some metadata about the chart itself.

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://localhost:8081/v1/rb/definition

Command to UPLOAD artifact for Definition Created:

curl -i --data-binary @vault-consul-dev.tar.gz -X POST http://localhost:8081/v1/rb/definition/test-rbdef/v1/content

Command to GET Definitions:

# Get all Definitions
curl -i http://localhost:8081/v1/rb/definition/

# Get one Definition
curl -i http://localhost:8081/v1/rb/definition/test-rbdef/v1

Command to DELETE Definitions:

#Delete all versions of definition
curl -i -X DELETE http://localhost:8081/v1/rb/definition/test-rbdef
#Delete a particular version of definition
curl -i -X DELETE http://localhost:8081/v1/rb/definition/test-rbdef/v1

Profiles API's

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
1. Contains the details for the profile and everything contained within
A HELM values override yaml file.
1. 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
1. All these files should have a corresponding entry in manifest.yaml file

Sample Profile is described in the above patch

Create the profile artifact

Creating a 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

manifest.yaml

---
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

Profile JSON Body

{
	"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

curl -i -d @create_rbprofile.json -X POST http://localhost:8081/v1/rb/definition/test-rbdef/v1/profile

Command to UPLOAD artifact for Profile

curl -i --data-binary @profile.tar.gz -X POST http://localhost:8081/v1/rb/definition/test-rbdef/v1/profile/p1/content

Command to GET Profiles

# Get all Profiles
curl -i http://localhost:8081/v1/rb/definition/test-rbdef/v1/profile

# Get one Profile
curl -i http://localhost:8081/v1/rb/definition/test-rbdef/v1/profile/p1

Command to DELETE Profile

curl -i -X DELETE http://localhost:8081/v1/rb/definition/test-rbdef/v1/profile/p1

Instantiation API's

Instantiate the created Profile via the following REST api

Using the following JSON:

{
    "cloud_region": "krd",
    "profile-name": "p1",
	"rb-name":"test-rbdef",
	"rb-version":"v1",
    "labels": {
	}
}

NOTE: Make sure that the namespace is already created before instantiation.
See MULTICLOUD-462 - Getting issue details... STATUS for more details.

Instantiate the profile with the ID provided above

Command to Instantiate a Profile

curl -d @create_rbinstance.json http://localhost:8081/v1/instance

This command returns the following JSON:

{
  "id": "ZKMTSaxv",
  "rb-name": "mongo",
  "rb-version": "v1",
  "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"
    }
  ]
}

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.

Command to Instantiate a Profile

curl -X DELETE http://localhost:8081/v1/instance/ZKMTSaxv

Configuration API's

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's

Command to POST (create) Template:

curl -i -d @create_config_template.json -X POST http://localhost:8081/v1/rb/definition/{name}/{version}/config-template/

With the following JSON content (create_config_template.json )

1
2
3
4

{
"name": "kafka_token"
"description": "testing Kafka Day 2 config configuration",
}

Command to UPLOAD Template:

curl -i --data-binary @kafka-config.tar.gz -X POST http://localhost:8081/v1/rb/definition/{name}/{version}/config-template/{name}

Command to GET Templates:

# Get all Templates
curl -i http://localhost:8081/v1/rb/definition/{name}/{version}/config-template

# Get one Template
curl -i http://localhost:8081/v1/rb/definition/{name}/{version}/config-template/{name}

Command to DELETE Templates:

curl -i -X DELETE http://localhost:8081/rb/definition/{name}/{version}/config-template/{name}

Example

Example Contents of Tar File

> cd demo/vnfs/DAaaS
> find kafka-config
kafka-config/values.yaml
kafka-config/Chart.yaml
kafka-config/templates
kafka-config/templates/topic.yaml

#Create a tar.gz for upload
> tar -cf kafka-config.tar kafka-config
> gzip kafka-config.tar

Configuration Values API's

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

curl -i -d @values.json -X POST http://localhost:8081/v1/rb/definition/{name}/{version}/profile/{name}/config

With the following JSON content (values.json )

{
  "template-name": "kafka_token"
  "config-name": "kafka_token_1"
  "description":"testing Kafka Day 2 config configuration",
   "values":{
      "namespace":"kafka",
      "topic":{
         "name":"orders",
         "cluster":"my-cluster",
         "partitions":10,
         "replicas":2
      }
   }
}

This command returns the following JSON which contains config-version id.

{
   "rb-name":"kafka",
   "rb-version":"kafka-config-1",
   "profile-name":"1234567890",
   "template-name": "kafka-token"
   "config-name": "kafka_token_1"
   "config-version":"1"
   }
}

Command to GET Configuration Values

# Get all Values
curl -i http://localhost:8081/v1/rb/definition/{name}/{version}/profile/{name}/config

# Get one Value with config name
curl -i http://localhost:8081/v1/rb/definition/{name}/{version}/profile/{name}/config/{name}

Command to DELETE Configuration Values

curl -i -X DELETE http://localhost:8081/v1/rb/definition/{name}/{version}/profile/{name}/config/{name}

Command to PUT (Modify) Configuration Values

curl -i -d @values.json -X PUT http://localhost:8081/v1/rb/definition/{name}/{version}/profile/{name}/config/{name}

With the following JSON content (values.json )

{
  "template-name": "kafka_token"
  "config-name": "kafka_token_1"
  "description":"testing Kafka Day 2 config configuration",
   "values":{
      "namespace":"kafka",
      "topic":{
         "name":"orders",
         "cluster":"my-cluster",
         "partitions":20,
         "replicas":2
      }
   }
}

This command returns the following JSON which contains config-version.

{
   "rb-name":"kafka",
   "rb-version":"kafka-config-1",
   "profile-name":"1234567890",
   "template-name": "kafka-token"
   "config-name": "kafka_token_1"
   "config-version":"3"
   }
}

Command to TAG configuration Values

This will add the tag name to the current config version

curl -i -d @values.json -X POST http://localhost:8081/v1/rb/definition/{name}/{version}/profile/{name}/tagit

With the following JSON content (values.json )

{
"tag-name": "my-tag"
}

Command to ROLLBACK configuration Values

Rollbacks configuration to a config version or a tag.

curl -i -d @values.json -X POST http://localhost:8081/v1/rb/definition/{name}/{version}/profile/{name}/rollback

With the following JSON content (values.json )

{
  "anyOf": [
    {
      "config-version": "<value>"
    },
    {
      "config-tag": "<tag name>"
    }
  ]
}

Reachability/Connectivity Info API's

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-record” : [
			{
                “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.

#Using a json file containing content as above;

curl -i -F "metadata=<jsonfile;type=application/json" -F file=@/home/ad_kkkamine/.kube/config -X POST http://localhost:8081/v1/connectivity-info

Command to GET Connectivity Info

curl -i -X GET http://localhost:8081/v1/connectivity-info/{name}

Command to DELETE Connectivity Info

curl -i -X DELETE http://localhost:8081/v1/connectivity-info/{name}

Command to UPDATE/PUT Connectivity Info

curl -i -d @update.json -X PUT http://localhost:8081/v1/connectivity-info/{name}