...
Only once this done should we be able to trigger migrate.
Assumptions:
- We assume that composition target is already primed
- Participants execute the effective pre-check.
- Pre-check is completely optional. it will be
- Only the participants can execute a effective precheck.
- Precheck is executed before the migration, if . If it fail or the migration will be not executed.is not supported, can the migration be executed?
- User receives User needs to receive the result of the precheck .Acm-runtime needs to handle the precheck fail in a different way it handles migration failon the outProperties result.
Solution: create a new flow for migration-precheck
...
User can send the action migration-precheck POST. The user can do the action migration POST after that. The migration flow will be unchanged and backwards-compatible.
- User send migration-precheck action
- Acm-runtime set the state of the instance in "MIGRATING-PRECHECK" deployState
- Acm-runtime sends migration-precheck message to participants (it will be AUTOMATION_COMPOSITION_MIGRATION message with Boolean flag "precheck" set to true)
- Participant receives migration-precheck message and executes the precheck and sends the result (it will be a new method "migratePrecheck()" that participant has to implement)
- Acm-runtime receives precheck-result messages from all participants
- Acm-runtime shows this result into the stateChangeResult (deployState will be in "DEPLOYED" state)
- NO_ERROR: means the migration is validNOT_VALID: means the migration is not valid (is better do no create confusion wit FAILED)supported (state will back as before the precheck-migration call)
- FAILED: means something went wrong during the migration precheck (state will be in "MIGRATING-PRECHECK")
- It will be implemented migratePrecheck() in participant-simulator to test all scenarios.
PlantUML Macro |
---|
@startuml
participant "ACM Runtime"
participant Participant
participant AutomationCompositionElementListener
alt "Priming Compositon Target"
"ACM Runtime" -> "ACM Runtime" : Create Compositon Target
"ACM Runtime" -> Participant : [ASYNC] Prime Compositon Target
Participant -> AutomationCompositionElementListener : Prime Compositon Target
AutomationCompositionElementListener -> Participant : Compositon Target primed
Participant -> "ACM Runtime" : [ASYNC] Compositon Target primed
end
alt "Migrating pre-check an instance to Compositon Target"
"ACM Runtime" -> Participant : [ASYNC] Message for migration pre-check from source to target composition
Participant -> AutomationCompositionElementListener : Migrate pre-check AC Element
AutomationCompositionElementListener -> Participant : Migrate supported / not supported
Participant -> "ACM Runtime" : [ASYNC] Migration pre-check completed
note right
Returns AUTOMATION_COMPOSITION_STATE_CHANGE message.
end note
end
alt "Migrating an instance to Compositon Target"
"ACM Runtime" -> Participant : [ASYNC] Message for migration from source to target composition
Participant -> AutomationCompositionElementListener : Migrate AC Element
AutomationCompositionElementListener -> Participant : Element instance Migrated
Participant -> "ACM Runtime" : [ASYNC] Migration completed
note right
Returns AUTOMATION_COMPOSITION_STATE_CHANGE message.
end note
end
@enduml |
Allowed operations
stateChangeResult | state | Allowed | Not Allowed Operation |
---|---|---|---|
FAILED | MIGRATING-PRECHECK | UNDEPLOY, MIGRATE_PRECHECK | UPDATE, DELETE, DEPLOY, MIGRATE, UNLOCK, LOCK |
TIMEOUT | MIGRATING-PRECHECK | UNDEPLOY, MIGRATE_PRECHECK | UPDATE, DELETE, DEPLOY, MIGRATE, UNLOCK, LOCK |
How the user can send the action migration-precheck POST?
...
Code Block | ||
---|---|---|
| ||
name: DemoInstance0
version: 1.0.1
compositionId: {{composition1Id}}
instanceId: {{instanceId}}
compositionTargetId: {{composition2Id}}
precheck: true
....................... |
What state suits for migration-precheck?
Differently in what happen in deploy, undeploy, update and migrate, the migration-precheck operation do not make changes in the applications (same will be for prepare and review). What state is most suitable for that operation?
Using deployState, lockState or a new subState does not impact the migration-precheck functionality, it is an implementation detail that it help to understand how to implement all new functionalities.