EMCO Resources with Status
There are currently two EMCO resources for which status may be queried.
- Network Intents
- Network Intents are defined for specific clusters
- Deployment Intent Groups
- Deployment Intent Groups are defined for a specific instantiation of a composite application and version, along with a composite profile and a set of placement and action intents
High level life cycle of the EMCO resources
- The EMCO resources and associated supporting resources are created using the EMCO APIs and stored into the EMCO resource database (i.e. MongoDB).
- When 'Instantiated' via EMCO API, the EMCO resources are rendered by the appropriate scheduler service ('ncm' for network intents, 'orchestrator' for deployment intent groups) into a set of Kubernetes resources (referred to hereafter as rsync resources) that are stored in the EMCO AppContext per cluster (i.e. etcd).
- The EMCO resource synchronizer service ('rsync') is then invoked to apply the rsync resources to the appropriate clusters - creating cluster resources.
The following information is tracked to report the state and status of an EMCO resource and its instantiation.
- The lifecycle state of the EMCO resource - e.g. Created, Instantiated, etc.
- The status of the rsync resources - e.g. Applied, Failed, etc.
- The status of the cluster resources - e.g. information about the resource from the cluster
Cluster Network Intent lifecycle
The state of the Cluster Network Intents is maintained in the Cluster document in the EMCO database. The states are:
- Created: Upon initial creation of the cluster. In this state, Network Intents may be added to the cluster.
- Applied: Once applied, the network intents are rendered to create appropriate rsync resources in the AppContext and rsync is then invoked to instantiates these to the cluster to create cluster resources.
URL: POST /v2/cluster-providers/{cluster-provider-name}/clusters/{cluster-name}/apply
In this state (for now), additional network intents may not be added, modified or deleted until the current ones are terminated
The cluster resource deleted from the EMCO database as well, until the current network intents are terminated
- Terminated: Causes rsync to delete the cluster resources from the destination clusters.
URL: POST /v2/cluster-providers/{cluster-provider-name}/clusters/{cluster-name}/terminate
This state is effectively similar to the Created state - network intents may be added, modified or deleted.
The cluster resource itself may be deleted (subject to deleting sub-resources first)
The Applied state may also be re-invoked to start a new set of rsync resources and cluster resources.
Deployment Intent Group lifecycle
The state of the Deployment Intent Group (DIG) is maintained in the Deployment Intent Group document in the EMCO database. The states are:
- Created: Upon creation of the DIG, intents may be added to the DIG. The DIG may be modified or deleted.
- Approved: Once the DIG is Approved, the DIG and its intents may not be modified or deleted. Modifying the DIG or its intents will change unapprove the DIG and set it back to the Created state.
URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/deployment-intent-groups/{deployment-intent-group-name}/approve
- Instantiated: When the DIG is Instantiated, the rsync resources are created in the AMCO AppContext and the rsync is invoked to create the cluster resources in the destination clusters.
URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/deployment-intent-groups/{deployment-intent-group-name}/instantiate
Once instantiated, the DIG and its intents may not be modified or deleted. The DIG must be Terminated first.
- Terminated: Causes rsync to delete the cluster resources from the destination clusters.
URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/deployment-intent-groups/{deployment-intent-group-name}/terminate
This state is effectively similar to the Approved state.
The Instantiated state may be re-invoked to start a new set of rsync resources and cluster resources.
AppContext State
The rsync process will maintain a top level state for the AppContext. The states are:
- Instantiating: Once rsync is invoked to instantiate an AppContext, the state will be set to Instantiating.
- Instantiated: Rsyinc will set the .AppContext state to Instantiated after all Resources in the AppContext have been Applied.
- InstantiateFailed: This indicates that one or more Resources Failed to be applied.
- PreTerminate: If rsync is invoked to terminate an AppContext which is still in the Instantiating state, rsync needs to shutdown any threads in the process of trying to instantiate resources before beginning the terminate sequence.
- Terminating: When terminate is invoked, this state will be entered directly if the AppContext is in Instantiated or InstantiateFailed state. Otherwise, it will enter this state from PreTerminate after the initialize sequence has been shutdown.
- Terminated: This indicates that rsync has successfully Deleted all resources.
- TerminateFailed: This indicates that rsync has received a failure response from one or more Resources when attempting to delete them.
Rsync resource state values
The state of the rsync resource is maintained in the EMCO AppContext by rsync. The status values are defined as follows.
- Pending: Upon initial creation by ncm (for cluster network intents) or orchestrator (for DIGs), the rsync resources will be initialized to a Pending status to indicate they have not been handled by rsync yet.
- Applied: This indicates that rsync has successfully applied the rsync resource to a destination cluster. This does not indicate anything about the actual status of the corresponding cluster resource(s) - other than it is expected that the cluster resource does exist.
- Failed: This indicates that rsync has received a failure response when either attempting to apply or delete the rsync resource from the destination cluster. rsync is taking no further action with this resource.
- Retrying: This indicates that rsync is continuing to attempt to apply or delete the rsync resource from the destination cluster. This may occur because connectivity to the destination cluster is currently unavailable, but may resume at a later time. This will continue until a different lifecyle state is invoked on the controlling EMCO resource.
- Terminated: This indicates that rsync has successfully deleted the rsync resource from the destination cluster. This does not indicate anything about the actual status of the corresponding cluster resource(s) - other than it is expected to that the cluster resource does exist or is in the process of terminating.
Cluster resource status
The status of resources deployed by rsync to clusters is detected as follows.
- When rsync instantiates rsync resources, it will also instantiate a ResourceBundleState CR to the cluster. For a given Composite Application, a ResourceBundleState CR will be deployed for each App (in the Composite App) per cluster. A label will be applied by rsync to all cluster resources of a given App and will be matched by label to the corresponding ResourceBundleState CR in the cluster. The label format is: "emco/deployment-id: <AppContext identifier>-<app-name>"
- A 'monitor' pod is present in each cluster is monitors all resources with the "emco/deployement-id" label. When it detects changes to those resources, it will update the matching ResourceBundleState CR with the details of the resource. In the example ResourceBundleState CR below, for example, all pod resources that are labeled with emco/deployment-id: 171887448792644816-sink will be included in the 'podStatuses' array.
A Watcher thread is started per cluster by rsync to watch for changes to ResourceBundleState CRs in the cluster. When an updated CR is detected, the Watcher retrieves it and saves it into the corresponding AppContext per App/Cluster so it is available to provide information for cluster resource queries.
The cluster resource status is provided in two forms.
- The actual status{} portion of the cluster resource (if present) is made available in the information returned via the ResourceBundleState CR.
- Summarized in a value as follows.
- Unknown: The unknown status represents the case where a ResourceBundleState CR has not been received yet, or that the ResourceBundleState CR does not support that resource type.
- NotPresent: For resource types (Kinds) that are supported by the ResourceBundleState CR, if an rsync resource does not have a corresponding cluster resource in the CR, then the cluster status of the resource is NotPresent.
- Present: For rsync resources with a corresponding cluster resource in the ResourceBundleState CR, the clustesr status is present.
- TBD: Further work can be done to summarize the Status{} portion of cluster resources to identify the status more precisely than Present - such as: Active, Ready, Not Ready, etc.
Instantiate Sequence
This illustrates the Deployment Intent Group instantiate sequence
Terminate Sequence
This illustrates the Deployment Intent Group terminate sequence
Status Query Sequence
This illustrates a status query sequence
Status Query
The status query, and variations with query parameters, on an EMCO resource will present the information described previously to the caller. The basic status query for the two EMCO resources discussed above will look like the following:
URL: GET /v2/cluster-providers/{cluster-provider-name}/clusters/{cluster-name}/status
URL: GET /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/deployment-intent-groups/{deployment-intent-group-name}/status
The following query parameters will be available:
output=<summary | all | detail | rsync>
default output value is: 'all'
summary: will just show the top level EMC resource state and aggregated resource statuses but no resource detail information
all: will include a list of resources showing basic resource identification and resource statuses
detail: includes in the resource list the metadata, spec, and status of the resource as received in the ResourceBundleState CR
rsync: similar to detail, but only includes in the resource list the rsync resources - so the metadata and spec information will be taken from the AppContext. No cluster status information will be included.
app=<appname>
default is all apps
This will filter the results of the query to show results only for the resources of the specified App(s).
cluster=<cluster>
default is all clusters
This will filter the results of the query to show results only for the specified cluster(s)
resource=<resource name>
default is all resources
This will filter the results of the query to show results only for the specified resource(s)
Output of Status Query
The following table shows the essential structure of the status query response with a description of which elements are present based on the 'output' parameter.
Format of the status query response | Description | 'summary' query | 'all' query | 'detail' query | 'rsync' query |
{ | |||||
"name": "<name>", | The name of the Deployment Intent Group or Cluster | X | X | X | X |
"project": "<project name>", | Present for the Deployment Intent Group | X | X | X | X |
"composite-app-name": "<composite-app-name>", | Present for the Deployment Intent Group | X | X | X | X |
"composite-app-version": "<composite-app-version>", | Present for the Deployment Intent Group | X | X | X | X |
"composite-profile-name": "<composite-profile-name>", | Present for the Deployment Intent Group | X | X | X | X |
"state": "[ Created, Approved, Instantiated, Terminated ]", | 'state' is the action made by the user | X | X | X | X |
"rsync-status": { | 'rsync-status' is the aggregated rsync-status of the resources - subject to query parameter filters | X | X | X | X |
"Pending": 0, | elements with zero can be dropped | X | X | X | X |
"Applied": 5, | X | X | X | X | |
"Failed": 2, | X | X | X | X | |
"Retrying": 3, | X | X | X | X | |
"Terminated": 0 | X | X | X | X | |
}, | X | X | X | X | |
"cluster-status" : { | 'cluster-status' is the aggregated cluster-status of the resources - subject to query parameter filters | X | X | X | |
"NotPresent": 0, | X | X | X | ||
"Present": 5, | X | X | X | ||
"Unknown": 5 | X | X | X | ||
}, | X | X | X | ||
"resources": [ | array of resources organized by app in the composite-app | X | X | X | |
{ | X | X | X | ||
"app-name": "collectd", | X | X | X | ||
"clusters": [ | array of clusters in the app | X | X | X | |
{ | X | X | X | ||
"name": "cluster1", | X | X | X | ||
"resources": [ | array of resources in the cluster | X | X | X | |
{ | X | X | X | ||
"GVK": { | The GVK will come from the AppContext except for cases where the resource is only a cluster resource - e.g. an rsync resource that is a Deployment can result in cluster resources of both Deployment and Pod(s). | X | X | X | |
"Group": "<group>", | X | X | X | ||
"Version": "<version>", | X | X | X | ||
"Kind": "<kind>" | X | X | X | ||
}, | X | X | X | ||
"Name": "<resource name>", | The name of the resource from the AppContext (or cluster as described for GVK) | X | X | X | |
"metadata": { }, | The 'metadata' element of the cluster resource as received in the ResourceBundleState CR. In the case of an 'output=rsync' query, this will be the 'metadata' element from the AppContext. | X | X | ||
"spec": { }, | The 'spec' element of the cluster resource as received in the ResourceBundleState CR. In the case of an 'output=rsync' query, this will be the 'metadata' element from the AppContext. | X | X | ||
"status": { }, | The 'status' element of the k8s resource as received in the ResourceBundleState CR (if the resource has one). In the case of an 'output=rsync' query, this will not be present. | X | |||
"rsync-status": "[ Pending | Instantiated | Failed | Retrying |Terminated ]", | "Pending" - is set by orchestrator before issuing an Instantiate command to rsync "Instantiate" - means rsync has successfully invoked deployment of the resource to the cluster "Failed" - means rsync got an explicit failure when invoking to the cluster "Retrying" - means connection to cluster is temporarily unavailable, rsync will continue to retry - applies to both instantiate and terminate sequences (initial thought is to detect this condition at a cluster level - but mark each resource) "Terminated" - means rsync has successfully invoked termination of the resource to the cluster | X | X | X | |
"cluster-status": "[ Unknown | NotPresent | Present | (tbd) ]" | Summary status for the resource from info obtained from the cluster (e.g. via the ResourceBundleState CR) "Unknown" - means a ResourceBundleState has not yet been received or the resource type is not supported in the ResourceBundleState CR "NotPresent" - the resource is not in the ResourceBundleState CR and it is supported. "Present" - the resource is present in the ResourceBundleState CR "tbd" - further status values can be derived as analysis of how to represent the full status {} object from the resource can be interpreted - e.g. 'Ready', 'Failed', 'Pending', etc. | X | X | ||
} | X | X | X | ||
] | X | X | X | ||
} | X | X | X | ||
] | X | X | X | ||
} | X | X | X | ||
] | X | X | X | ||
} | X | X | X |
Examples of queries and outputs:
Basic default query of a composite application - ('type' is 'all')
Query by cluster2
Query by app2
Query by cluster2 and app2
Concept for query of historical instances EMCO resources
Once an EMCO resource has been instantiated and terminated. It may be instantiated again. On termination, it is possible to save the AppContext of the old instance so that it can be
Query of a previous composite application instance (no instance value specified will list all instances)
Query of a previous composite application instance (other query parameters would apply as shown above)