1.2 Deregister a Participant
----------------------------
-Participant Deregistration is performed by a Participant when it shuts down. It deregisters its ID and type with the ACM runtime. The participant should already have cleared down all its ACM Element instances and set their states to "Not In Service".
+Participant Deregistration is performed by a Participant when it shuts down. It deregisters its ID and type with the ACM runtime.
.. image:: ../images/system-dialogues/DeregisterParticipant.png
.. image:: ../images/system-dialogues/UpdateAcElementsResponse.png
-3.5 Undeploy Automation Composition Instance
+3.5 Migrate Automation Composition Instance
+-------------------------------------------
+The user requests the AC Instance to be migrated using a REST endpoint. The ACM Runtime orders the AC Instance to be migrated.
+
+.. image:: ../images/system-dialogues/MigrateAcInstance.png
+
+Each participant migrated its AC Element from the AC Instance
+
+.. image:: ../images/system-dialogues/MigrateAcElements.png
+
+The ACM Runtime receives and stores the responses.
+
+.. image:: ../images/system-dialogues/MigrateAcElementsResponse.png
+
+3.6 Undeploy Automation Composition Instance
--------------------------------------------
The user requests the AC Instance to be undeployed using a REST endpoint. The ACM Runtime orders the AC Instance to be undeployed.
.. image:: ../images/system-dialogues/UndeployResponseStored.png
-3.6 Read Automation Composition Instances
+3.7 Read Automation Composition Instances
-----------------------------------------
.. image:: ../images/system-dialogues/ReadAcInstances.png
-3.7 Unlock Automation Composition Instance
+3.8 Unlock Automation Composition Instance
------------------------------------------
The user requests the AC Instance to be unlocked using a REST endpoint. The ACM Runtime orders the AC Instance to be unlocked on Participants.
.. image:: ../images/system-dialogues/UnlockResponseStored.png
-3.8 Lock Automation Composition Instance
+3.9 Lock Automation Composition Instance
----------------------------------------
The user requests the AC Instance to be locked using a REST endpoint. The ACM Runtime orders the AC Instance to be locked on Participants.
.. image:: ../images/system-dialogues/LockResponseStored.png
-3.9 Update Operational State on Automation Composition Instance
----------------------------------------------------------------
+3.10 Update Operational State on Automation Composition Instance
+----------------------------------------------------------------
.. image:: ../images/system-dialogues/UpdateOperationalState.png
-3.10 Update Usage State on Automation Composition Instance
+3.11 Update Usage State on Automation Composition Instance
----------------------------------------------------------
.. image:: ../images/system-dialogues/UpdateUsageState.png
-3.11 Failure handling in ACM
+3.12 Failure handling in ACM
----------------------------
After any ACM operation is completed, one of the following result messages will be updated in the ACM. These result values are
updated along with the overall state of the ACM instance.
.. image:: ../images/system-dialogues/SuccessAcmResult.png
The result value should be updated as 'FAILED' by the participants when any failures occurred.
-Also in case of failures, the overall state of the composition remains in any of the transitioning states (DEPLOYING, UNDEPLOYING, PRIMING, UPDATING)
+Also in case of failures, the overall state of the composition/instance remains in any of the transitioning states (DEPLOYING, UNDEPLOYING, PRIMING, DEPRIMING, UPDATING, MIGRATING)
with the appropriate result values updated by the participant.
.. image:: ../images/system-dialogues/FailedAcmResult.png
-Runtime marks the operation result with the value 'TIMEOUT' when the participant gets disconnected from the ACM-R in the middle of any ACM operation.
-When the participant fails to report the periodic heartbeat during an ACM operation, the operation result is then marked as 'TIMEOUT' by the ACM-R after the configured waiting limit is
-reached.
+Runtime marks the operation result with the value 'TIMEOUT' when the participant fails to report the message back during an ACM operation,
+the operation result is then marked as 'TIMEOUT' by the ACM-R after the configured waiting limit is reached.
.. image:: ../images/system-dialogues/TimeoutAcmResult.png
An ACM operation has to be completed and updated with any of the above specified result values in order to allow the user to trigger subsequent requests.
The user cannot trigger any state change events before the operation gets completed. When an operation is marked 'TIMEOUT', the following scenarios are applicable.
- - The participant might come back ONLINE and complete the operation to mark the result with 'NO_ERROR' or 'FAILED'
+ - The participant might complete the operation to mark the result with 'NO_ERROR' or 'FAILED'
- The user can trigger another state change event to the ACM.
+The following flow shown and example of deployment that get stuck, and the user decide to undeploy.
+
+.. image:: ../images/system-dialogues/TimeoutParticipant.png
+
+
+3.13 OFF_LINE handling in ACM
+-----------------------------
+Runtime marks the participant state with the value 'OFF_LINE' when the participant fails to report the periodic heartbeat,
+the participant state is then marked as 'OFF_LINE' by the ACM-R after the configured waiting limit is reached.
+That scenario might happen when participant is shutdown, in that scenario all on going operations with that participant are marked 'TIMEOUT' due the missing messages back.
+
+The user cannot trigger any state change events when participant state is 'OFF_LINE'.
+
+.. image:: ../images/system-dialogues/OfflineAcmResult.png
+
+When a participant state is marked 'OFF_LINE', it might come back ONLINE and the user can trigger state change events to the ACM.
+
End of Document
Code Review / policy / parent.git / blobdiff