Getting Logical Cloud Creation/Deletion/Modification operations Status is missing

Today, it is possible to get the composite application instantiation/termination/Upgrade status can be obtained via status API. Status API is needed by services that take advantage of EMCO APIs. They are required for multiple reasons. One of the main reasons is to create a workflow of operations.

There is no status API present for operations related to logical cloud creation, termination and modifications.

Problem observed by one of the users of EMCO. This user is creating a logical cloud, followed by deployment (instantiation) of a composite application on the logical cloud. Both operations are issued in a script one after another. EMCO due to its parallel execution application resources being deployed before the logical cloud is created. This is resulting in failure of composite application deployment as namespace is not present.

One way to address this problem is for the user script to wait for completion of logical-cloud creation across all clusters before issuing the instantiate request of the composite application. For users to create that kind of script, there shall be a status API by DCM. Script can periodically check on the logical cloud status and at the right time can move to the next step.

Status API capabilities expected are:

  • Get the status of complete logical-cloud.
  • Get the status of logical-cloud on a specific cluster.
  • Get the status of logical-cloud for a specific set of resources across all clusters.
  • Get the status of logical-cloud for a specific cluster on a specific set of resources.

In addition, it is also needed for users to get notified whenever status changes. This is required if the user is a microservice, which doesn't like to poll for the status on a periodic basis. A user microservice can register for status notifications and when notified can get the detailed status via status API.

Some thoughts on status notifications.

  • Register for status notification by giving endpoint information and notification criteria (any change, change only for a set of resources across a set of clusters).
  • Unregister

DCM is expected to honor these registration and inform the target endpoints when it observes the status change.

Edited by SRINIVASA ADDEPALLI