Page History

...

Only once this done should we be able to trigger migrate.

Assumptions:

• Can we We assume that composition target is already primed?
• Only the participants can execute a Participants execute the effective pre-check.
• Is Pre-check is completely optional? . it will be executed before the migration, if . If it fail or the migration is not supported, can the migration be executed?
• User needs to receive receives the result of the precheck on the outProperties result.

Solution: create a new flow for migration-precheck

...

• 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)
• It will add a new NOT_VALID state in stateChangeResult
• Acm-runtime receives precheck-result messages from all participants
• Acm-runtime shows this result into the stateChangeResult
  • NO_ERROR: means the migration is supported (deployState will be in "DEPLOYED")NOT_VALID: means the migration is not supported (deployState will be in "DEPLOYED"state will back as before the precheck-migration call)
  • FAILED: means something went wrong during the migration precheck (deployState state will be in "MIGRATING-PRECHECK")
• It will be implemented migratePrecheck() in participant-simulator to test all scenarios.

@startuml
participant "ACM Runtime"
participant Participant
participant AutomationCompositionElementListener

alt "Priming Compositon Target"instance
  Id"ACM andRuntime" Composition-> Ids"ACM exist"Runtime" : Create Compositon Target
  "ACM Runtime" -> Participant : [ASYNC] Migration pre-check message 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

...

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.