Page Comparison

...

1. The k8splugin provide an API to get the status of a running instance
2. The status fields need to be mapped to the AAI data model
3. 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

...

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

...

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

...

status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2019-07-19T21:47:51Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2019-07-19T21:48:55Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2019-07-19T21:48:55Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2019-07-19T21:47:50Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: docker://eb3f5ae847a5a3aa38c95cba3aea0bf6a15fce12bcd220206de8b513c481154f
    image: edgexfoundry/docker-edgex-mongo:0.8.0
    imageID: docker-pullable://edgexfoundry/docker-edgex-mongo@sha256:e2cf9380555867ed747be392284117be3b50cfdff04e13e6f57cb51d86f331b3
    lastState: {}
    name: edgex-mongo
    ready: true
    restartCount: 0
    state:
      running:
        startedAt: "2019-07-19T21:48:27Z"
  hostIP: 172.25.55.139
  phase: Running
  podIP: 10.42.0.13
  qosClass: BestEffort
  startTime: "2019-07-19T21:47:51Z"

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:

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