This page contains details of planning and implementation of the migration functionality for instances in ACM-R. Rest interface users will be able to call a new endpoint in order to trigger the moving/migration of an instance from a source composition definition to a target composition definition. Calls to migrate the instance will take place on an instance-by-instance basis. The caller will have to supply the following parameters when making the call to migrate an instance.
- Source Composition Definition Id - The Id of the composition that the instance is currently based on.
- Target Composition Definition Id - The Id of the composition that the instance is to be migrated to.
- Instance Id - The Id of the instance that the caller wishes to migrate.
This operation will only be possible if:
- the source composition is primed
- the target composition is primed and contains the same element definitions present in the source composition
- the instance is deployed and based on the the source composition
Migration Sequence Diagram
Note: The functionality for the upload of a new composition definition already exists
PlantUML Macro |
---|
@startuml Title Migration Sequence participant UserRest participant ACM participant DB participant Participants group Create New Composition type for Migration UserRest -> ACM : Composition Definitions ACM -> DB : Saved Definition UserRest -> ACM : Prime Definition ACM -> Participants: Prime Definition end group group Migration per Instance /'Instance migration from source to target composition type. '/ UserRest -> ACM : Migrate Instance (InstanceId, sourceCompId, targetCompId) note top Instance migration from source to target composition type. end note alt "instance Id and Composition Ids exist" ACM -> UserRest : 202 Async Operation ACM -> DB : Definition Validation (v1 no new elements/structure) ACM -> DB : instance and AC Element will be set in a transitional state (UPGRADING) ACM -> Participants : Move from source to target compostioncomposition Participants -> ACM : Move completed ACM -> DB : instance and AC Element will be set in a final state (DEPLOYED)\n and Comp Def IDs change for instance and AC Element else ACM -> UserRest : 400 Bad Reqest end end group @enduml |
End point, fail and rollback
Solution 1
Upgrade:
PUT /onap/policy/clamp/acm/v2/compositions/{{source_composition_id}}/instances/{{instance_id}}/upgrade
{
compositionTarget = "{{target_composition_id}}"
}
After instance has been upgraded successfully, it could be retrieved using:
GET /onap/policy/clamp/acm/v2/compositions/{{target_composition_id}}/instances/{{instance_id}}
In success scenario, is it possible to revert the upgrade, using the same endpoint with composition id inverted.
If upgrade fail, the instance is still based to {{source_composition_id}} with deployOrder "UPGRADING" and stateChangeResult "FAILED".
In this scenario, is it possible to rollback the upgrade, using the flag "rollback" set to true.
PUT /onap/policy/clamp/acm/v2/compositions/{{source_composition_id}}/instances/{{instance_id}}/upgrade
{
rollback = "true",
compositionTarget = "{{target_composition_id}}"
}
Solution 2
Upgrade:
PUT /onap/policy/clamp/acm/v2/compositions/{{source_composition_id}}/instances/{{instance_id}}
{
deployOrder = "UPGRADE",
compositionTarget = "{{target_composition_id}}"
}
After instance has been upgraded successfully, it could be retrieved using:
GET /onap/policy/clamp/acm/v2/compositions/{{target_composition_id}}/instances/{{instance_id}}
In success scenario, is it possible to revert the upgrade, using the same endpoint with composition id inverted.
If upgrade fail, the instance is still based to {{source_composition_id}} with deployOrder "UPGRADING" and stateChangeResult "FAILED".
In this scenario, is it possible to rollback the upgrade, with the deployOrder set to "UPGRADE_ROLLBACK".
PUT /onap/policy/clamp/acm/v2/compositions/{{source_composition_id}}/instances/{{instance_id}}
{
deployOrder = "UPGRADE_ROLLBACK",
compositionTarget = "{{target_composition_id}}"
}
Other solutions