AAI Update after Resource Instantiation

1 Heatbridge code (non-K8S)
2 Example of AAI data for vFW (non-K8S) use case
- 2.1 Robot testsuite examples
- 2.2 SO Openstack adapter examples
3 Structure of Resources
- 3.1 Instance Body
- 3.2 GVK
4 Structure of Status
- 4.1 Deployment Status
  - 4.1.1 Deployment Status
- 4.2 POD Status
  - 4.2.1 Pod Status

Active and Available Inventory (AAI) needs to be updated when a Resource Bundle is instantiated in one of the cloud regions managed by the k8splugin.

The requires that;

The k8splugin provide an API to get the status of a running instance
The status fields need to be mapped to the AAI data model
A REST API call to AAI needs to be made when the status of resources changes.

Heatbridge code (non-K8S)

The robot testsuite uses a heatbridge python script to generate the AAI updates. The SO openstack adapter also has built-in java code to perform the AAI update. See: Code which performs AAI Update (HeatBridge)

Example of AAI data for vFW (non-K8S) use case

Robot testsuite examples

Here is an example from a vFW instantiate test (different from the previous) that shows the AAI bulk PUT request the robot heatbridge code uses to update AAI. See: Example of vFW AAI Update PUT request via Robot

Shows example output of AAI contents when the vFWCL test is executed - part of which includes running Heatbridge - which performs an AAI update to ensure 'vserver' objects are present. See: Example of AAI data for vFWCL with Robot

SO Openstack adapter examples

Here is an example of the PUT request to AAI performed by SO: Example AAI update PUT command - using SO heatbridge code path

Here is an example the AAI contents after SO openstack adapter has performed heatbridge update: Example of AAI update results - using SO based heatbridge method

Structure of Resources

Here is how the an instance created by K8splugin is tracked

Instance Body

{
  "id": "fnKPvVAL",
  "request": {
    "rb-name": "edgex",
    "rb-version": "v1",
    "profile-name": "profile2",
    "cloud-region": "k8sregionone",
    "labels": null
  },
  "namespace": "testns2",
  "resources": [
    {
      "GVK": {
        "Group": "",
        "Version": "v1",
        "Kind": "Service"
      },
      "Name": "profile2-edgex-ui"
    },
    {
      "GVK": {
        "Group": "apps",
        "Version": "v1beta2",
        "Kind": "Deployment"
      },
      "Name": "profile2-edgex-vault"
    }
  ]
}

Each Resource is tracked as two parts that uniquely identify it in a given namespace

Name and GVK

GVK

{
	"Group": "apps",
    "Version": "v1",
    "Kind": "Deployment"
}

Structure of Status

The structure of status fields is not finalized yet. However, we would like to include the entire status as returned by Kubernetes for the object.

This means that the status can vary based on the type of object being queried.

Deployment Status

status:
  availableReplicas: 1
  conditions:
  - lastTransitionTime: "2019-07-19T21:48:55Z"
    lastUpdateTime: "2019-07-19T21:48:55Z"
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: "2019-07-19T21:47:50Z"
    lastUpdateTime: "2019-07-19T21:48:55Z"
    message: ReplicaSet "profile2-edgex-mongo-d64f6c7c8" has successfully progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing
  observedGeneration: 1
  readyReplicas: 1
  replicas: 1
  updatedReplicas: 1

POD Status

Pod Status

Given this disparate nature of Status' we need to filter the list of resources we update status for and figure out a way to summarize this status to a simple Ready|Pending|Failed status.

Eg:

A deployment status would be READY if replicas == readyReplicas
A POD status would be READY if all its containerStatuses have ready:True