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

End point, fail and rollback

Solution 1

UpgradeMigrate:

PUT /onap/policy/clamp/acm/v2/compositions/{{source_composition_id}}/instances/{{instance_id}}/upgrademigrate
{
    compositionTarget = "{{target_composition_id}}"
}

After instance has been upgraded migrated 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 upgrademigration, using the same endpoint with composition id inverted.

If upgrade migration fail, the instance is still based to {{source_composition_id}} with deployOrder "UPGRADINGMIGRATING" and stateChangeResult "FAILED".

In this scenario, is it possible to retry or rollback the upgrademigration, using the flag "rollback" set to true.

Retry:

PUT /onap/policy/clamp/acm/v2/compositions/{{source_composition_id}}/instances/{{instance_id}}/upgrademigrate
{
    compositionTarget = "{{target_composition_id}}"
}

Rollback:

PUT /onap/policy/clamp/acm/v2/compositions/{{source_composition_id}}/instances/{{instance_id}}/upgrademigrate
{
    rollback = "true",
    compositionTarget = "{{target_composition_id}}"
}

Solution 2

UpgradeMigration:

PUT /onap/policy/clamp/acm/v2/compositions/{{source_composition_id}}/instances/{{instance_id}}
{
    deployOrder = "UPGRADEMIGRATE",
    compositionTarget = "{{target_composition_id}}"
}

After instance has been upgraded migrated 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 upgrademigration, using the same endpoint with composition id ids inverted.

If upgrade migration fail, the instance is still based to {{source_composition_id}} with deployOrder "UPGRADINGMIGRATING" and stateChangeResult "FAILED".

In this scenario, is it possible to retry or rollback the upgrademigration, with the deployOrder set to "UPGRADEMIGRATION_ROLLBACK".

Retry:

PUT /onap/policy/clamp/acm/v2/compositions/{{source_composition_id}}/instances/{{instance_id}}
{
    deployOrder = "UPGRADEMIGRATE",
    compositionTarget = "{{target_composition_id}}"
}

Rollback:

PUT /onap/policy/clamp/acm/v2/compositions/{{source_composition_id}}/instances/{{instance_id}}
{
    deployOrder = "UPGRADEMIGRATION_ROLLBACK",
    compositionTarget = "{{target_composition_id}}"
}

Other solutions