Automation Composition Management manages a number of states of various types to manage the lifecycle of compositions. Those states are described here. Please also see the ACM System Level Dialogues page to see the system dialogues that change states and how states interrelate in detail. Please also see ITU Recommendation X.731, which is reflected in the states of AC Element Instances.
Participant State
ACParticipant states are NOT managed by ACM but the state of a participant is recorded and supervised by ACM.
PlantUML Macro |
---|
@startuml
[*] --> ONLINE: Register
ONLINE --> ONLINE: Heartbeat
ONLINE --> OFFLINE: Timeout
OFFLINE --> ONLINE: Heartbeat
ONLINE --> [*]: Deregister
OFFLINE --> [*]: Deregister
@enduml |
Automation Composition Type State
The states that an Automation Composition Type can have are shown in the diagram below.
PlantUML Macro |
---|
@startuml
|
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
- Composition in UNINITIALIZED state: all elements of a composition are in UNINITIALIZED state, all applications are not deployed and policy types are not deployed and not present in Api.
- User triggers to move the composition from UNINITIALIZED to PASSIVE: runtime-acm moves elements from UNINITIALIZED state to UNINITIALIZED_TO_PASSIVE.
- Element in UNINITIALIZED_TO_PASSIVE:
- participant-ks8: deploys applications
- participant-policy: creates policy types in Api and deploys them with Pap.
- participant-http: configures applications.
- Element in PASSIVE state:
- participant-ks8: applications are deployed.
- participant-policy: policy types are create in Api and deployed with Pap.
- participant-http: applications are configured.
- Composition in PASSIVE state: all elements are in PASSIVE state, all applications are deployed and configured.
- User triggers to move the composition from PASSIVE to UNINITIALIZED: runtime-acm moves elements from PASSIVE state to PASSIVE_TO_UNINITIALIZED.
- Element in UNINITIALIZED_TO_PASSIVE:
- participant-ks8: undeploys applications
- participant-policy: undeploys policy types with Pap and deletes them in Api.
- participant-http: do nothing
- Element in UNINITIALIZED state:
- participant-ks8: applications are undeployed.
- participant-policy: policy types are not deployed and not present in Api.
PlantUML Macro |
---|
@startuml
'https://plantuml.com/state-diagram
state UNINITIALIZED
state UNINITIALIZED_TO_PASSIVE
state PASSIVE_TO_UNINITIALIZED
state PASSIVE
[*] --> UNINITIALIZED
UNINITIALIZED --> UNINITIALIZED_TO_PASSIVE
PASSIVE_TO_UNINITIALIZED --> UNINITIALIZED
PASSIVE --> PASSIVE_TO_UNINITIALIZED
UNINITIALIZED_TO_PASSIVE --> PASSIVE
@enduml |
Proposed State Machine
PlantUML Macro |
---|
@startuml 'https://plantuml.com/state-diagram state UNINITIALIZED state UNINITIALIZED_TO_PASSIVE state PASSIVE_TO_UNINITIALIZED state PASSIVE state PASSIVE_TO_RUNNING state RUNNING_TO_PASSIVE state RUNNING state RUNNING_TO_PASSIVE_ERROR state PASSIVE_TO_RUNNING_ERROR state RUNNING state RUN_ERROR [*] --> UNINITIALIZED UNINITIALIZEDCOMMISSIONED: Commission COMMISSIONED --> UNINITIALIZED_TO_PASSIVE PASSIVE_TO_UNINITIALIZED [*]: Decommission COMMISSIONED --> PRIMING: UNINITIALIZED UNINITIALIZED_TO_PASSIVEPrime PRIMED --> PRIMING: PASSIVEPrime PASSIVEPRIMING --> PASSIVE_TO_RUNNING PASSIVEPRIMED: AC Element Types\nall PRIMED PRIMING --> PASSIVE_TO_UNINITIALIZED PASSIVE_TO_RUNNINGDEPRIMING: Deprime PRIMED --> RUNNING PASSIVE_TO_RUNNINGDEPRIMING: Deprime DEPRIMING --> PASSIVE_TO_RUNNING_ERROR PASSIVE_TO_RUNNING_ERROR COMMISSIONED: AC Element Types\nall DEPRIMED @enduml |
Automation Composition Element Type State
The states that an Automation Composition Element Type can have on ACM Runtime are shown in the diagram below.
PlantUML Macro |
---|
@startuml [*] --> PASSIVE_TO_RUNNING RUNNINGCOMMISSIONED: Commission COMMISSIONED --> RUNNING_TO_PASSIVE RUNNING_TO_PASSIVE[*]: Decommission COMMISSIONED --> PASSIVE RUNNING_TO_PASSIVEPRIMING: Prime PRIMED --> RUNNING_TO_PASSIVE_ERROR RUNNING PRIMING: Prime PRIMING --> RUN_ERROR RUN_ERROR PRIMED: AC Element Type Primed\nresponse from Participant PRIMING --> RUNNING RUN_ERRORDEPRIMING: Deprime PRIMED --> RUNNING_TO_PASSIVE RUNNING_TO_PASSIVE_ERROR DEPRIMING: Deprime DEPRIMING --> RUNNING_TO_PASSIVE COMMISSIONED: AC Element Type Deprimed\nresponse from Participant @enduml |
State Machine for Automation Composition Elements
Current State Machine
TBC
Proposed State Machine
The states that an Automation Composition Element Type can have on a Participant are shown in the diagram below.
PlantUML Macro |
---|
@startuml 'https://plantuml [*] --> PRIMED: Prime from\nACM Runtime PRIMED --> PRIMED: Prime from ACM Runtime PRIMED --> [*]: Deprime from\nACM Runtime @enduml |
Automation Composition Instance State
The states that an Automation Composition Instance can have are shown in the diagram below.
PlantUML Macro |
---|
@startuml.com/state-diagram state UNINITIALIZED state UNINITIALIZED_TO_PASSIVE state PASSIVE_TO_UNINITIALIZED state PASSIVE state PASSIVE_TO_RUNNING state RUNNING_TO_PASSIVE state RUNNING state RUNNING_TO_PASSIVE_ERROR state PASSIVE_TO_RUNNING_ERROR state RUNNING state RUN_ERROR [*] --> UNDEPLOYED: UNINITIALIZEDCreate UNINITIALIZEDUNDEPLOYED --> UNINITIALIZED_TO_PASSIVE PASSIVE_TO_UNINITIALIZED[*]: Delete UNDEPLOYED --> UNINITIALIZED UNINITIALIZED_TO_PASSIVEDEPLOYING: Deploy DEPLOYING --> PASSIVE PASSIVE DEPLOYED: AC Element Instances\nall DEPLOYED DEPLOYING --> PASSIVE_TO_RUNNING PASSIVE UNDEPLOYING: Undeploy DEPLOYED --> PASSIVE_TO_UNINITIALIZED PASSIVE_TO_RUNNING UNDEPLOYING: Undeploy UNDEPLOYING --> RUNNING PASSIVE_TO_RUNNING --> PASSIVE_TO_RUNNING_ERROR PASSIVE_TO_RUNNING_ERROR UNDEPLOYED: AC Element Instances\nall UNDEPLOYED state DEPLOYED { [*] --> PASSIVE_TO_RUNNING RUNNINGLOCKED: Deploy LOCKED --> RUNNING_TO_PASSIVE RUNNING_TO_PASSIVE[*]: Undeploy LOCKED --> UNLOCKING: PASSIVE RUNNING_TO_PASSIVEUnlock UNLOCKING --> RUNNING_TO_PASSIVE_ERROR RUNNING UNLOCKED: AC Element Instances\nall UNLOCKED UNLOCKED --> RUN_ERROR RUN_ERRORLOCKING: Lock UNLOCKING --> LOCKING: RUNNING RUN_ERRORLock LOCKING --> RUNNING_TO_PASSIVE RUNNING_TO_PASSIVE_ERROR --> RUNNING_TO_PASSIVELOCKED: AC Element Instances\nall LOCKED } @enduml |
...
Automation Composition Element Instance State
...
- Composition in UNINITIALIZED state: all elements of a the composition are in UNINITIALIZED state, all applications are not deployed and policy types are not deployed and not present in Api.
- User triggers to move the composition from UNINITIALIZED to PASSIVE: runtime-acm moves elements from UNINITIALIZED state to UNINITIALIZED_TO_PASSIVE.
- Element in UNINITIALIZED_TO_PASSIVE:
- participant-ks8: deploys applications
- participant-policy: creates policy types in Api and deploys them with Pap.
- participant-http: checks if applications are healthy.
- Element in UNINITIALIZED_TO_PASSIVE_ERROR state: participant got error during deploy.
- Composition in UNINITIALIZED_TO_PASSIVE_ERROR state: at least one element is in UNINITIALIZED_TO_PASSIVE_ERROR state.
- User can re-try UNINITIALIZED_TO_PASSIVE.
- User can go back to UNINITIALIZED.
- Element in PASSIVE state:
- participant-ks8: applications are deployed.
- participant-policy: policy types are create in Api and deployed with Pap.
- participant-http: applications are healthy but not configured yet.
- Composition in PASSIVE state: all elements are moved to PASSIVE, all applications are deployed but not configured.
- User triggers to move the composition from PASSIVE to RUNNING: runtime-ACM moves elements from PASSIVE state to PASSIVE_TO_RUNNING.
- Element in PASSIVE_TO_RUNNING state:
- participant-ks8: do nothing (maybe checks if applications are running).
- participant-policy: do nothing (maybe checks if policy types are running).
- participant-http: configures applications.
- Element in PASSIVE_TO_RUNNING_ERROR state: participant got error during configuration.
- Composition in PASSIVE_TO_RUNNING_ERROR state: at least one element is in PASSIVE_TO_RUNNING_ERROR state.
- Element in RUNNING state:
- participant-ks8: applications are deployed (periodically checks if applications are running).
- participant-policy: policy types are create in Api and deployed with Pap.
- participant-http: applications are healthy and configured (periodically checks if applications are healthy).
- Composition in RUNNING state: all elements of a ACM are in RUNNING state, all applications are running.
- Element in RUN_ERROR state: participant got error during running state (it periodically checks if applications are running).
- Composition in RUN_ERROR state: at least one element is in RUN_ERROR state
- User could decide to move the composition from RUN_ERROR to PASSIVE state.
- Application has been restarted by kubernetes, Participant detects that the application is running and move the element from RUN_ERROR to RUNNING.
- User triggers to move the composition from RUNNING to PASSIVE: runtime-acm moves elements from RUNNING state to RUNNING_TO_PASSIVE.
- Element in RUNNING_TO_PASSIVE:
- participant-ks8: do nothing
- participant-policy: do nothing
- participant-http: remove configuration
- Element in RUNNING_TO_PASSIVE_ERROR state: participant got error during removing configuration
- Composition in RUNNING_TO_PASSIVE_ERROR state: at least one element is in RUNNING_TO_PASSIVE_ERROR state.
- User triggers to move the composition from PASSIVE state to UNINITIALIZED: runtime-acm moves elements from PASSIVE state to PASSIVE_TO_UNINITIALIZED.
- Element in PASSIVE_TO_UNINITIALIZED:
- participant-ks8: undeploys applications
- participant-policy: undeploys policy types with Pap and deletes them in Api.
- participant-http: do nothing
- Element in PASSIVE_TO_UNINITIALIZED_ERROR state: participant got error during undeployment
- Composition in PASSIVE_TO_UNINITIALIZED_ERROR state: at least one element is in PASSIVE_TO_UNINITIALIZED_ERROR state.
- Element in UNINITIALIZED state:
- participant-ks8: applications are undeployed.
- participant-policy: policy types are not deployed and not present in Api.
- In any Error status the User can re-try the operation.
Note:
Whit this solution, User can move from RUNNING to PASSIVE, update the service template related to the configuration (participant-http) when applications are still up, and after move from PASSIVE to RUNNING.
The states that an Automation Composition Element Instance can have on ACM Runtime are shown in the diagram below.
PlantUML Macro |
---|
@startuml
|
PlantUML Macro |
@startuml 'https://plantuml.com/state-diagram state UNINITIALIZED state UNINITIALIZED_TO_PASSIVE state PASSIVE_TO_UNINITIALIZED state PASSIVE state UNINITIALIZED_TO_PASSIVE_ERROR state PASSIVE_TO_UNINITIALIZED_ERROR state PASSIVE_TO_RUNNING state RUNNING_TO_PASSIVE state RUNNING state RUNNING_TO_PASSIVE_ERROR state PASSIVE_TO_RUNNING_ERROR state RUNNING state RUN_ERROR [*] --> UNDEPLOYED: UNINITIALIZEDCreate UNINITIALIZEDUNDEPLOYED --> UNINITIALIZED_TO_PASSIVE PASSIVE_TO_UNINITIALIZED[*]: Delete UNDEPLOYED --> DEPLOYING: UNINITIALIZED PASSIVE_TO_UNINITIALIZEDDeploy DEPLOYING --> PASSIVE_TO_UNINITIALIZED_ERROR PASSIVE_TO_UNINITIALIZED_ERROR --> PASSIVE_TO_UNINITIALIZED UNINITIALIZED_TO_PASSIVEDEPLOYED: AC Element\nInstance DEPLOYED DEPLOYING --> UNDEPLOYING: PASSIVE UNINITIALIZED_TO_PASSIVEUndeploy DEPLOYED --> UNINITIALIZED_TO_PASSIVE_ERROR UNINITIALIZED_TO_PASSIVE_ERRORUNDEPLOYING: Undeploy UNDEPLOYING --> UNINITIALIZED_TO_PASSIVE UNINITIALIZED_TO_PASSIVE_ERROR --> PASSIVE_TO_UNINITIALIZED PASSIVE UNDEPLOYED: AC Element\nInstance UNDEPLOYED state DEPLOYED { [*] --> PASSIVE_TO_RUNNING PASSIVE LOCKED: Deploy LOCKED --> PASSIVE_TO_UNINITIALIZED PASSIVE_TO_RUNNING [*]: Undeploy LOCKED --> UNLOCKING: RUNNING PASSIVE_TO_RUNNINGUnlock UNLOCKING --> PASSIVE_TO_RUNNING_ERROR PASSIVE_TO_RUNNING_ERROR --> PASSIVE_TO_RUNNING RUNNINGUNLOCKED: AC Element\nInstance UNLOCKED UNLOCKED --> RUNNING_TO_PASSIVE RUNNING_TO_PASSIVE LOCKING: Lock UNLOCKING --> LOCKING: PASSIVE RUNNING_TO_PASSIVE --> RUNNING_TO_PASSIVE_ERROR RUNNINGLock LOCKING --> RUN_ERROR RUN_ERROR --> RUNNING RUN_ERROR --> RUNNING_TO_PASSIVE RUNNING_TO_PASSIVE_ERROR --> RUNNING_TO_PASSIVE @enduml |
Second Proposed State Machine
- Composition in UNINITIALIZED state: all elements of a the composition are in UNINITIALIZED state, all applications are not deployed and policy types are not deployed and not present in Api.
- User triggers to move the composition from UNINITIALIZED to PASSIVE: runtime-acm moves elements from UNINITIALIZED state to UNINITIALIZED_TO_PASSIVE.
- Element in UNINITIALIZED_TO_PASSIVE:
- participant-ks8: deploys applications
- participant-policy: creates policy types in Api and deploys them with Pap.
- participant-http: configures applications.
- Element in UNINITIALIZED_TO_PASSIVE_ERROR state: participant got error during deploy.
- Composition in UNINITIALIZED_TO_PASSIVE_ERROR state: at least one element is in UNINITIALIZED_TO_PASSIVE_ERROR state.
- User can re-try UNINITIALIZED_TO_PASSIVE.
- User can go back to UNINITIALIZED.
- Element in PASSIVE state:
- participant-ks8: applications are deployed.
- participant-policy: policy types are create in Api and deployed with Pap.
- participant-http: applications are configured.
- Composition in PASSIVE state: all elements are moved to PASSIVE, all applications are deployed and configured. Runtime-ACM automatically moves the composition from PASSIVE to RUNNING: runtime-ACM moves elements from PASSIVE state to PASSIVE_TO_RUNNING.
- Element in PASSIVE_TO_RUNNING state:
- participant-ks8: starts monitoring if applications are running.
- participant-policy: do nothing (maybe starts monitoring if policy types are running).
- participant-http: starts monitoring if applications are healthy.
- Element in PASSIVE_TO_RUNNING_ERROR state: participant got error during configuration.
- Composition in PASSIVE_TO_RUNNING_ERROR state: at least one element is in PASSIVE_TO_RUNNING_ERROR state.
- Element in RUNNING state:
- participant-ks8: monitoring if applications are running.
- participant-policy: do nothing (maybe monitoring if policy types are running).
- participant-http: monitoring if applications are healthy.
- Composition in RUNNING state: all elements of a ACM are in RUNNING state, all applications are running.
- Element in RUN_ERROR state: participant got error during running state (it periodically checks if applications are running).
- Composition in RUN_ERROR state: at least one element is in RUN_ERROR state
- User could decide to move the composition from RUN_ERROR to PASSIVE state.
- Application has been restarted by kubernetes, Participant detects that the application is running and move the element from RUN_ERROR to RUNNING.
- User triggers to move the composition from RUNNING to PASSIVE: runtime-acm moves elements from RUNNING state to RUNNING_TO_PASSIVE.
- Element in RUNNING_TO_PASSIVE:
- participant-ks8: stop monitoring
- participant-policy: stop monitoring
- participant-http: stop monitoring
- User triggers to move the composition from PASSIVE state to UNINITIALIZED: runtime-acm moves elements from PASSIVE state to PASSIVE_TO_UNINITIALIZED.
- Element in PASSIVE_TO_UNINITIALIZED:
- participant-ks8: undeploys applications
- participant-policy: undeploys policy types with Pap and deletes them in Api.
- participant-http: do nothing
- Element in PASSIVE_TO_UNINITIALIZED_ERROR state: participant got error during undeployment
- Composition in PASSIVE_TO_UNINITIALIZED_ERROR state: at least one element is in PASSIVE_TO_UNINITIALIZED_ERROR state.
- Element in UNINITIALIZED state:
- participant-ks8: applications are undeployed.
- participant-policy: policy types are not deployed and not present in Api.
- In any Error status the User can re-try the operation.
Note:
Whit this solution, User can move from RUNNING to PASSIVE, update the service template related to the configuration (participant-http) when applications are still up, and after move from PASSIVE to RUNNING.
LOCKED: AC Element\nInstance LOCKED
}
@enduml |
The states that an Automation Composition Element Instance can have on a Participant are shown in the diagram below.
PlantUML Macro |
---|
@startuml
|
PlantUML Macro |
@startuml 'https://plantuml.com/state-diagram state UNINITIALIZED state UNINITIALIZED_TO_PASSIVE state PASSIVE_TO_UNINITIALIZED state PASSIVE state UNINITIALIZED_TO_PASSIVE_ERROR state PASSIVE_TO_UNINITIALIZED_ERROR state PASSIVE_TO_RUNNING state RUNNING_TO_PASSIVE state RUNNING state RUN_ERROR [*] --> UNINITIALIZED UNINITIALIZEDDEPLOYING: Deploy DEPLOYING --> UNINITIALIZED_TO_PASSIVE PASSIVE_TO_UNINITIALIZED --> UNINITIALIZED PASSIVE_TO_UNINITIALIZED --> PASSIVE_TO_UNINITIALIZED_ERROR PASSIVE_TO_UNINITIALIZED_ERROR --> PASSIVE_TO_UNINITIALIZED UNINITIALIZED_TO_PASSIVEDEPLOYED: AC Element\nInstance DEPLOYED\nRespond with\nAC Element State Update DEPLOYING --> PASSIVE UNINITIALIZED_TO_PASSIVEUNDEPLOYING: Undeploy DEPLOYING --> UNINITIALIZED_TO_PASSIVE_ERROR UNINITIALIZED_TO_PASSIVE_ERROR --> UNINITIALIZED_TO_PASSIVE UNINITIALIZED_TO_PASSIVE_ERROR --> PASSIVE_TO_UNINITIALIZED PASSIVE --> PASSIVE_TO_RUNNING PASSIVE --> PASSIVE_TO_UNINITIALIZED PASSIVE_TO_RUNNING --> RUNNING RUNNING --> RUNNING_TO_PASSIVE RUNNING_TO_PASSIVE --> PASSIVE RUNNING --> RUN_ERROR RUN_ERROR --> RUNNING RUN_ERROR --> RUNNING_TO_PASSIVE @enduml |
ACM Element States in Participants
This section describes the state handling in ACM Elements in Participants
The following states are the only states in participants:
PlantUML Macro | ||||
---|---|---|---|---|
| ||||
@startuml
state UNINITIALIZED
state PASSIVE
state RUNNING
[*] --> UNINITIALIZED: Created by\nACM Runtime
UNINITIALIZED --> PASSIVE: Initializing
PASSIVE --> RUNNING: Activating
RUNNING --> PASSIVE: Passivating
PASSIVE --> UNINITIALIZED: Uninitializing
@enduml |
Then, a Control Loop Element can be running a number of operations, each of which has an operational state:
...
To
State
...
A Control Loop Element has a status indicator
...
Each participant also records a log of all operations that occur, recording the information below:
...
To
State
...
[*]: Deploy Failed\nRespond with\nAC Element State Update
DEPLOYED --> UNDEPLOYING: Undeploy
UNDEPLOYING --> [*]: Undeployed\nRespond with\nAC Element State Update
state DEPLOYED {
[*] --> LOCKED
LOCKED --> [*]
LOCKED --> UNLOCKING: Unlock
UNLOCKING --> UNLOCKED: AC Element\nInstance UNLOCKED
UNLOCKED --> LOCKING: Lock
UNLOCKING --> LOCKING: Lock
LOCKING --> LOCKED: AC Element\nInstance LOCKED
}
@enduml |