Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

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:

  1. manifest.yaml
    1. Contains the details for the profile and everything contained within
  2. A HELM values override yaml file.
    1. It can have any name as long as it matches the corresponding entry in the manifest.yaml
  3. 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_id": "krd",
    "rb_profile_id": "12345678-8888-4578-3344-987654398731",
    "csar_id": "94e414f6-9ca4-11e8-bb6a-52540067263b"
    "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:

{
  "vnf_id":"3c13",
  "cloud_region_id":"krd",
  "namespace":"testnamespace1",
  "vnf_components": {
    "deployment":["krd-testnamespace1-3c13-test-rbprofile-vault-consul-dev"],
    "service":["krd-testnamespace1-3c13-aaf-sms-db"]
  }
}

Delete Instantiated Kubernetes resources

The vnf_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/vnf_instances/krd/testnamespace1/3c13

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}

  • No labels