The current ACM state machine works but it is incosistent in the way it handles error states or failed transitions. A composition and its elements can get "stuck" in transition states.
We need to
- Specify what the current state machine is for both compositions and elements and describe what the state machine for both should be
- Specify what the behaviour of the runtime and participants should be in each state
- Specify what the behaviour should be for the runtime and participants should be in transitions
Specifically we need to clarify:
- State of the composition elements
- State of the overall composition is derived from the composition element states
- Admin state/Running state
- When all the elements are fully up and configured, the go to state Passive, when all elements are in Passive, the full composition goes to Passive
- Error states: Are they parallel sates or part of the same state?
- There should “it didn’t work” states like “Passive-Error” or “Run_Error” (names to be decided later)
- Describe what the “Running” state means and what the participant should do in Passive->Running and Running->Passive transitions.
- Say a K8S service crashes, how do we feed that back? Running_Error. The state of the POD is only checked during startup. It is not periodically checked. There should be supervision.
State Machine for Automation Compositions
Current State Machine
- ACM in UNINITIALIZED state: all elements of a ACM are in UNINITIALIZED state, all applications are not deployed and policy types are not deployed and not present in Api.
- User triggers to move ACM from UNINITIALIZED to PASSIVE: all elements of a ACM are in UNINITIALIZED_TO_PASSIVE, all applications are getting deployed and configured, and policy types are getting created in Api and deployed with Pap.
- Element in PASSIVE state:
- ks8: application is deployed.
- policy: a policy type is create in Api and deployed with Pap.
- http: application is configured.
- ACM in PASSIVE state: all applications are deployed and configured.
- User triggers to move ACM from PASSIVE to UNINITIALIZED: all elements of a ACM are in PASSIVE_TO_UNINITIALIZED, all applications are getting undeployed, and policy types are undeployed with Pap and delete in Api.
Proposed State Machine
State Machine for Automation Composition Elements
Current State Machine
TBC
Proposed State Machine
Proposed State Machine
- ACM in UNINITIALIZED state: all elements of a ACM are in UNINITIALIZED state, all applications are not deployed and policy types are not deployed and not present in Api.
- User triggers to move ACM from UNINITIALIZED to RUNNING: all elements of a ACM are in UNINITIALIZED_TO_PASSIVE, all applications are getting deployed and policy types are getting created in Api and deployed with Pap.
- ACM in UNINITIALIZED_TO_PASSIVE_ERROR state: got error during deploy.
- Element in PASSIVE state: application is deployed or a policy type is create in Api and deployed with Pap.
- ACM in PASSIVE state: applications are deployed, but not configured yet. In this state, runtime-ACM triggers elements in state PASSIVE_TO_RUNNING.
- Element in PASSIVE_TO_RUNNING: applications are getting configured.
- ACM in PASSIVE_TO_RUNNING_ERROR state: error during configuration.
- ACM in RUNNING state: all elements of a ACM are in RUNNING state, all applications are running.