[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16455523#comment-16455523
 ] 

ASF subversion and git services commented on CLOUDSTACK-10323:
--------------------------------------------------------------

Commit d6cbd774b76a044efbdbc531acd5c8c1925cc1d2 in cloudstack's branch 
refs/heads/master from [~rafaelweingartner]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=d6cbd77 ]

[CLOUDSTACK-10323] Allow changing disk offering during volume migration  (#2486)

* [CLOUDSTACK-10323] Allow changing disk offering during volume migration

This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), which 
provided root admins an override mechanism to move volumes between storage 
systems types (local/shared) even when the disk offering would not allow such 
operation. To complete the work, we will now provide a way for administrators 
to enter a new disk offering that can reflect the new placement of the volume. 
We will add an extra parameter to allow the root admin inform a new disk 
offering for the volume. Therefore, when the volume is being migrated, it will 
be possible to replace the disk offering to reflect the new placement of the 
volume.

The API method will have the following parameters:

* storageid (required)
* volumeid (required)
* livemigrate(optional)
* newdiskofferingid (optional) – this is the new parameter

The expected behavior is the following:

* If “newdiskofferingid” is not provided the current behavior is maintained. 
Override mechanism will also keep working as we have seen so far.
* If the “newdiskofferingid” is provided by the admin, we will execute the 
following checks
** new disk offering mode (local/shared) must match the target storage mode. If 
it does not match, an exception will be thrown and the operator will receive a 
message indicating the problem.
** we will check if the new disk offering tags match the target storage tags. 
If it does not match, an exception will be thrown and the operator will receive 
a message indicating the problem.
** check if the target storage has the capacity for the new volume. If it does 
not have enough space, then an exception is thrown and the operator will 
receive a message indicating the problem.
** check if the size of the volume is the same as the size of the new disk 
offering. If it is not the same, we will ALLOW the change of the service 
offering, and a warning message will be logged.

We execute the change of the Disk offering as soon as the migration of the 
volume finishes. Therefore, if an error happens during the migration and the 
volume remains in the original storage system, the disk offering will keep 
reflecting this situation.

* Code formatting

* Adding a test to cover migration with new disk offering (#4)

* Adding a test to cover migration with new disk offering

* Update test_volumes.py

* Update test_volumes.py

* fix test_11_migrate_volume_and_change_offering

* Fix typo in Java doc


> Change disk offering when volume is migrated to different type of storage 
> pool.
> -------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-10323
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323
>             Project: CloudStack
>          Issue Type: Improvement
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>    Affects Versions: 4.12
>            Reporter: Rafael Weingärtner
>            Assignee: Rafael Weingärtner
>            Priority: Major
>             Fix For: 4.12
>
>
> This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), 
> which provided root admins an override mechanism to move volumes between 
> storage systems types (local/shared) even when the disk offering would not 
> allow such operation. To complete the work, we will now provide a way for 
> administrators to enter a new disk offering that can reflect the new 
> placement of the volume. We will add an extra parameter to allow the root 
> admin inform a new disk offering for the volume. Therefore, when the volume 
> is being migrated, it will be possible to replace the disk offering to 
> reflect the new placement of the volume.
> The API method will have the following parameters: 
> * storageid (required)
> * volumeid (required)
> * livemigrate(optional)
> * newdiskofferingid (optional) – this is the new parameter
> The expected behavior is the following: 
> * If “newdiskofferingid” is not provided the current behavior is maintained. 
> Override mechanism will also keep working as we have seen so far. 
> * If the “newdiskofferingid” is provided by the admin, we will execute the 
> following checks
> ** new disk offering mode (local/shared) must match the target storage mode. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** we will check if the new disk offering tags match the target storage tags. 
> If it does not match, an exception will be thrown and the operator will 
> receive a message indicating the problem.
> ** check if the target storage has the capacity for the new volume. If it 
> does not have enough space, then an exception is thrown and the operator will 
> receive a message indicating the problem.
> ** check if the size of the volume is the same as the size of the new disk 
> offering. If it is not the same, we will ALLOW the change of the service 
> offering, and a warning message will be logged.
> We execute the change of the Disk offering as soon as the migration of the 
> volume finishes. Therefore, if an error happens during the migration and the 
> volume remains in the original storage system, the disk offering will keep 
> reflecting this situation



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to