Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

To monitor the resources that are scheduled by orchestrator following follow is steps are required required.

During instantiation of rsync instantiation call:

  • Add Label to each resource at the time of instantiation including pods.
  • The label is of the format emco/deployment-id: project-name+composite-app-name+deployment-intent-group+app-name
  • Create CR with the format for each app in each cluster. This should be added in the appcontext of the application:

...

  • Read all clusters in the instantiation path for the composite app. Start watcher routine for the cluster for which watcher is not running. The watcher watches for changes to the ResourceBundleState CR's.
  • Continue with normal instantiation flow. 

Watcher Flow:

  • No Watcher is triggered every time there is a change in any resource of the app. On receiving a callback read rsync reads the CR obtained from the callback. The ResourceBundleState CR will have the status of the resources populated.

...

  • Get the  appcontext id from MongoDB based on the key project, composite app, version, and deployment-intent-group
  • Store the above information in the appcontext(etcd) for the app based on based on the cluster and app name (also available in label)

...

On getting the Status API call in the orchestrator

URL:  /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/deployment-intent-groups/{deployment-intent-group-name}/status

read status from all the apps and clusters from the appcontext(etcd). Interpret the status of each resource in each app and cluster and come up with the status for each resource (Ready/Terminated/Fail/..) for all apps in all clusters. Also, decide the final status for the composite application (Ready/Terminated/Fail/...) and return all this data to the caller.

Also support Queries like:

...