[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-26 Thread ASF subversion and git services (JIRA)

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

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 

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-26 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-26 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on a change in pull request #2486: 
[CLOUDSTACK-10323] Allow changing disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#discussion_r184533044
 
 

 ##
 File path: server/src/main/java/com/cloud/storage/VolumeApiServiceImpl.java
 ##
 @@ -2097,26 +2079,102 @@ public Volume migrateVolume(MigrateVolumeCmd cmd) {
 }
 }
 
-return orchestrateMigrateVolume(vol.getId(), destPool.getId(), 
liveMigrateVolume);
+return orchestrateMigrateVolume(vol, destPool, liveMigrateVolume, 
newDiskOffering);
 }
 
-private Volume orchestrateMigrateVolume(long volumeId, long destPoolId, 
boolean liveMigrateVolume) {
-VolumeVO vol = _volsDao.findById(volumeId);
-assert (vol != null);
-StoragePool destPool = 
(StoragePool)dataStoreMgr.getDataStore(destPoolId, DataStoreRole.Primary);
-assert (destPool != null);
+/**
+ * Retrieve the new disk offering UUID that might be sent to replace the 
current one in the volume being migrated.
 
 Review comment:
   If you read as "it (the method) retrieves the new .". Then, yes, I guess 
it should be "Retrieves".
   I will change that.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-26 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

GabrielBrascher commented on a change in pull request #2486: [CLOUDSTACK-10323] 
Allow changing disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#discussion_r184505828
 
 

 ##
 File path: server/src/main/java/com/cloud/storage/VolumeApiServiceImpl.java
 ##
 @@ -2097,26 +2079,102 @@ public Volume migrateVolume(MigrateVolumeCmd cmd) {
 }
 }
 
-return orchestrateMigrateVolume(vol.getId(), destPool.getId(), 
liveMigrateVolume);
+return orchestrateMigrateVolume(vol, destPool, liveMigrateVolume, 
newDiskOffering);
 }
 
-private Volume orchestrateMigrateVolume(long volumeId, long destPoolId, 
boolean liveMigrateVolume) {
-VolumeVO vol = _volsDao.findById(volumeId);
-assert (vol != null);
-StoragePool destPool = 
(StoragePool)dataStoreMgr.getDataStore(destPoolId, DataStoreRole.Primary);
-assert (destPool != null);
+/**
+ * Retrieve the new disk offering UUID that might be sent to replace the 
current one in the volume being migrated.
 
 Review comment:
   I think that it should be "Retrieves", right?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-26 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

GabrielBrascher commented on a change in pull request #2486: [CLOUDSTACK-10323] 
Allow changing disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#discussion_r184524300
 
 

 ##
 File path: server/src/main/java/com/cloud/storage/VolumeApiServiceImpl.java
 ##
 @@ -2097,26 +2079,102 @@ public Volume migrateVolume(MigrateVolumeCmd cmd) {
 }
 }
 
-return orchestrateMigrateVolume(vol.getId(), destPool.getId(), 
liveMigrateVolume);
+return orchestrateMigrateVolume(vol, destPool, liveMigrateVolume, 
newDiskOffering);
 }
 
-private Volume orchestrateMigrateVolume(long volumeId, long destPoolId, 
boolean liveMigrateVolume) {
-VolumeVO vol = _volsDao.findById(volumeId);
-assert (vol != null);
-StoragePool destPool = 
(StoragePool)dataStoreMgr.getDataStore(destPoolId, DataStoreRole.Primary);
-assert (destPool != null);
+/**
+ * Retrieve the new disk offering UUID that might be sent to replace the 
current one in the volume being migrated.
+ * If no disk offering UUID is provided we return null. Otherwise, we 
perform the following checks.
+ * 
+ *  Is the disk offering UUID entered valid? If not, an  {@link 
InvalidParameterValueException} is thrown;
+ *  If the disk offering was already removed, we thrown an {@link 
InvalidParameterValueException} is thrown;
+ *  We then check if the user executing the operation has access to 
the given disk offering.
+ * 
+ *
+ * If all checks pass, we move forward returning the disk offering object.
+ */
+private DiskOfferingVO retrieveAndValidateNewDiskOffering(MigrateVolumeCmd 
cmd) {
+String newDiskOfferingUuid = cmd.getNewDiskOfferingUuid();
+if (org.apache.commons.lang.StringUtils.isBlank(newDiskOfferingUuid)) {
+return null;
+}
+DiskOfferingVO newDiskOffering = 
_diskOfferingDao.findByUuid(newDiskOfferingUuid);
+if (newDiskOffering == null) {
+throw new InvalidParameterValueException(String.format("The disk 
offering informed is not valid [id=%s].", newDiskOfferingUuid));
+}
+if (newDiskOffering.getRemoved() != null) {
+throw new InvalidParameterValueException(String.format("We cannot 
assign a removed disk offering [id=%s] to a volume. ", 
newDiskOffering.getUuid()));
+}
+Account caller = CallContext.current().getCallingAccount();
+_accountMgr.checkAccess(caller, newDiskOffering);
+return newDiskOffering;
+}
+
+/**
+ * Performs the validations required for replacing the disk offering while 
migrating the volume of storage. If no new disk offering is provided, we do not 
execute any validation.
+ * If a disk offering is informed, we then proceed with the following 
checks.
+ * 
+ *  We check if the given volume is of ROOT type. We cannot change the 
disk offering of a ROOT volume. Therefore, we thrown an {@link 
InvalidParameterValueException}.
+ *  We the disk is being migrated to shared storage and the new disk 
offering is for local storage (or vice versa), we throw an {@link 
InvalidParameterValueException}. Bear in mind that we are validating only the 
new disk offering. If none is provided we can override the current disk 
offering. This means, placing a volume with shared disk offering in local 
storage and vice versa.
+ *  We then proceed checking if the tags of the new disk offerings 
match the tags of the target storage. If they do not match an {@link 
InvalidParameterValueException} is thrown.
+ * 
+ *
+ * If all of the above validations pass, we check if the size of the new 
disk offering is different from the volume. If it is, we log a warning message.
+ */
+protected void validateConditionsToReplaceDiskOfferingOfVolume(VolumeVO 
volume, DiskOfferingVO newDiskOffering, StoragePool destPool) {
+if (newDiskOffering == null) {
+return;
+}
+if (Volume.Type.ROOT.equals(volume.getVolumeType())) {
+throw new InvalidParameterValueException(String.format("Cannot 
change the disk offering of a ROOT volume [id=%s].", volume.getUuid()));
+}
+if ((destPool.isShared() && newDiskOffering.getUseLocalStorage()) || 
destPool.isLocal() && newDiskOffering.isShared()) {
+throw new InvalidParameterValueException("You cannot move the 
volume to a shared storage and assing a disk offering for local storage and 
vice versa.");
+}
+String storageTags = getStoragePoolTags(destPool);
+if (!StringUtils.areTagsEqual(storageTags, newDiskOffering.getTags())) 
{
+throw new 

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-16 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-381610781
 
 
   @nitin-maharana are you LGTM here?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-11 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-380504152
 
 
   Trillian test result (tid-2488)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 97660 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2486-t2488-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_certauthority_root.py
   Intermitten failure detected: /marvin/tests/smoke/test_primary_storage.py
   Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
   Intermitten failure detected: /marvin/tests/smoke/test_routers.py
   Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py
   Intermitten failure detected: /marvin/tests/smoke/test_ssvm.py
   Intermitten failure detected: /marvin/tests/smoke/test_vm_life_cycle.py
   Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 61 look OK, 6 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_01_add_primary_storage_disabled_host | `Error` | 0.74 | 
test_primary_storage.py
   test_01_primary_storage_nfs | `Error` | 0.12 | test_primary_storage.py
   ContextSuite context=TestStorageTags>:setup | `Error` | 0.21 | 
test_primary_storage.py
   test_04_restart_network_wo_cleanup | `Failure` | 4.11 | test_routers.py
   test_02_list_snapshots_with_removed_data_store | `Error` | 1.16 | 
test_snapshots.py
   test_08_migrate_vm | `Error` | 18.91 | test_vm_life_cycle.py
   test_01_cancel_host_maintenace_with_no_migration_jobs | `Failure` | 1.14 | 
test_host_maintenance.py
   test_02_cancel_host_maintenace_with_migration_jobs | `Error` | 2.31 | 
test_host_maintenance.py
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 1.56 | 
test_hostha_kvm.py
   test_hostha_kvm_host_degraded | `Failure` | 1503.52 | test_hostha_kvm.py
   test_hostha_kvm_host_fencing | `Failure` | 619.78 | test_hostha_kvm.py
   test_hostha_kvm_host_recovering | `Failure` | 621.92 | test_hostha_kvm.py
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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 

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-10 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

nitin-maharana commented on a change in pull request #2486: [CLOUDSTACK-10323] 
Allow changing disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#discussion_r175389327
 
 

 ##
 File path: server/src/main/java/com/cloud/storage/VolumeApiServiceImpl.java
 ##
 @@ -2097,26 +2079,102 @@ public Volume migrateVolume(MigrateVolumeCmd cmd) {
 }
 }
 
-return orchestrateMigrateVolume(vol.getId(), destPool.getId(), 
liveMigrateVolume);
+return orchestrateMigrateVolume(vol, destPool, liveMigrateVolume, 
newDiskOffering);
 }
 
-private Volume orchestrateMigrateVolume(long volumeId, long destPoolId, 
boolean liveMigrateVolume) {
-VolumeVO vol = _volsDao.findById(volumeId);
-assert (vol != null);
-StoragePool destPool = 
(StoragePool)dataStoreMgr.getDataStore(destPoolId, DataStoreRole.Primary);
-assert (destPool != null);
+/**
+ * Retrieve the new disk offering UUID that might be sent to replace the 
current one in the volume being migrated.
+ * If no disk offering UUID is provided we return null. Otherwise, we 
perform the following checks.
+ * 
+ *  Is the disk offering UUID entered valid? If not, an  {@link 
InvalidParameterValueException} is thrown;
+ *  If the disk offering was already removed, we thrown an {@link 
InvalidParameterValueException} is thrown;
+ *  We then check if the user executing the operation has access to 
the given disk offering.
+ * 
+ *
+ * If all checks pass, we move forward returning the disk offering object.
+ */
+private DiskOfferingVO retrieveAndValidateNewDiskOffering(MigrateVolumeCmd 
cmd) {
+String newDiskOfferingUuid = cmd.getNewDiskOfferingUuid();
+if (org.apache.commons.lang.StringUtils.isBlank(newDiskOfferingUuid)) {
+return null;
+}
+DiskOfferingVO newDiskOffering = 
_diskOfferingDao.findByUuid(newDiskOfferingUuid);
+if (newDiskOffering == null) {
+throw new InvalidParameterValueException(String.format("The disk 
offering informed is not valid [id=%s].", newDiskOfferingUuid));
+}
+if (newDiskOffering.getRemoved() != null) {
+throw new InvalidParameterValueException(String.format("We cannot 
assign a removed disk offering [id=%s] to a volume. ", 
newDiskOffering.getUuid()));
+}
+Account caller = CallContext.current().getCallingAccount();
+_accountMgr.checkAccess(caller, newDiskOffering);
+return newDiskOffering;
+}
+
+/**
+ * Performs the validations required for replacing the disk offering while 
migrating the volume of storage. If no new disk offering is provided, we do not 
execute any validation.
+ * If a disk offering is informed, we then proceed with the following 
checks.
+ * 
 
 Review comment:
   Same here.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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 

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-10 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-380077312
 
 
   @PaulAngus a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-10 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

PaulAngus commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-380076997
 
 
   @blueorangutan test
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-10 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-379994394
 
 
   @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-10 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-379994205
 
 
   yup, let me run it again @blueorangutan test 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-379883955
 
 
   @borisstoyanov with that change in the test case, now the test we created 
for this PR passed. Some tests failed, but they are different from the last run.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-379883393
 
 
   Trillian test result (tid-2471)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 91858 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2486-t2471-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_certauthority_root.py
   Intermitten failure detected: /marvin/tests/smoke/test_primary_storage.py
   Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
   Intermitten failure detected: /marvin/tests/smoke/test_routers.py
   Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py
   Intermitten failure detected: /marvin/tests/smoke/test_vm_life_cycle.py
   Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 61 look OK, 6 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_01_add_primary_storage_disabled_host | `Error` | 0.61 | 
test_primary_storage.py
   test_01_primary_storage_nfs | `Error` | 0.13 | test_primary_storage.py
   ContextSuite context=TestStorageTags>:setup | `Error` | 0.24 | 
test_primary_storage.py
   test_04_restart_network_wo_cleanup | `Failure` | 3.27 | test_routers.py
   test_02_list_snapshots_with_removed_data_store | `Error` | 1.15 | 
test_snapshots.py
   test_08_migrate_vm | `Error` | 17.79 | test_vm_life_cycle.py
   test_01_cancel_host_maintenace_with_no_migration_jobs | `Failure` | 6.34 | 
test_host_maintenance.py
   test_02_cancel_host_maintenace_with_migration_jobs | `Error` | 2.29 | 
test_host_maintenance.py
   test_hostha_kvm_host_fencing | `Failure` | 1491.43 | test_hostha_kvm.py
   test_hostha_kvm_host_recovering | `Failure` | 616.59 | test_hostha_kvm.py
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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 

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-08 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-379571068
 
 
   @DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-08 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

DaanHoogland commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-379571001
 
 
   @blueorangutan test


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-07 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-379493578
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1889


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-07 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-379491614
 
 
   @rafaelweingartner a Jenkins job has been kicked to build packages. I'll 
keep you posted as I make progress.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-04-07 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-379491537
 
 
   @blueorangutan package


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-28 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-376943966
 
 
   @borisstoyanov I amended the code as you suggested.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-28 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-376943966
 
 
   @borisstoyanov I ammended the code as you suggested.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-376492335
 
 
   @rafaelweingartner if we add this in the marvin tests it should clean before 
migration, can you just add it before it tries to migrate?
   ```
   if hasattr(pool, 'tags'):
   StoragePool.update(self.apiclient, id=pool.id, tags="")
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-24 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-375602995
 
 
   Now the errors changed, it increased the number of them. The new test case 
that was added keeps failing.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-375602995
 
 
   Now the errors changed, it increased the number of them. However, the new 
test case that was added keeps failing.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-375567577
 
 
   Trillian test result (tid-2403)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 42229 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2486-t2403-kvm-centos7.zip
   Intermitten failure detected: 
/marvin/tests/smoke/test_affinity_groups_projects.py
   Intermitten failure detected: /marvin/tests/smoke/test_affinity_groups.py
   Intermitten failure detected: /marvin/tests/smoke/test_certauthority_root.py
   Intermitten failure detected: 
/marvin/tests/smoke/test_deploy_virtio_scsi_vm.py
   Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
   Intermitten failure detected: /marvin/tests/smoke/test_volumes.py
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 61 look OK, 6 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_DeployVmAntiAffinityGroup_in_project | `Error` | 58.44 | 
test_affinity_groups_projects.py
   test_DeployVmAntiAffinityGroup | `Error` | 63.06 | test_affinity_groups.py
   test_04_rvpc_privategw_static_routes | `Failure` | 370.47 | 
test_privategw_acl.py
   test_11_migrate_volume_and_change_offering | `Error` | 130.68 | 
test_volumes.py
   test_04_rvpc_network_garbage_collector_nics | `Failure` | 540.19 | 
test_vpc_redundant.py
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 2.44 | 
test_hostha_kvm.py
   test_hostha_kvm_host_fencing | `Failure` | 675.83 | test_hostha_kvm.py
   test_hostha_kvm_host_recovering | `Failure` | 623.78 | test_hostha_kvm.py
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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 

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-22 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-375426587
 
 
   @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-22 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-375426295
 
 
   @rafaelweingartner let me run this again, don't know why it appeared.
   @blueorangutan test


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-22 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-375313966
 
 
   @borisstoyanov are these errors something that I should take a look into? I 
noticed that the test you included is failing as well.
   
   I looked at the error of the new test, and it seems you are trying to change 
the service offering to a new one that does not have the tags of the target 
storage.
   
   `Target Storage [id=0818cecf-5f99-3b1e-beb2-5f0669c7b5ba] tags 
[storage.overprovisioning.factor] does not match new disk offering 
[id=a2992784-662b-4cad-b833-38c46136f97e] tags [null].'}, accountid : 
u'9f16aecc-2c1d-11e8-8460-06d348010705'}\n"]`


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-22 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-375313966
 
 
   @borisstoyanov are these errors something that I should take a look into? I 
noticed that the test you included is failing as well.
   
   I look at the error of the new test, and it seems you are trying to change 
the service offering to a new one that does not have the tags of the target 
storage.
   
   `Target Storage [id=0818cecf-5f99-3b1e-beb2-5f0669c7b5ba] tags 
[storage.overprovisioning.factor] does not match new disk offering 
[id=a2992784-662b-4cad-b833-38c46136f97e] tags [null].'}, accountid : 
u'9f16aecc-2c1d-11e8-8460-06d348010705'}\n"]`


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-20 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-374707349
 
 
   Trillian test result (tid-2396)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 32771 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2486-t2396-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_certauthority_root.py
   Intermitten failure detected: /marvin/tests/smoke/test_volumes.py
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py
   Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 64 look OK, 3 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_11_migrate_volume_and_change_offering | `Error` | 131.28 | 
test_volumes.py
   test_04_rvpc_network_garbage_collector_nics | `Failure` | 537.61 | 
test_vpc_redundant.py
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 2.96 | 
test_hostha_kvm.py
   test_hostha_kvm_host_fencing | `Error` | 7.97 | test_hostha_kvm.py
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-20 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-374519572
 
 
   @blueorangutan test


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-20 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-374519699
 
 
   @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-374426739
 
 
   Trillian test result (tid-2393)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 32550 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2486-t2393-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_certauthority_root.py
   Intermitten failure detected: 
/marvin/tests/smoke/test_deploy_virtio_scsi_vm.py
   Intermitten failure detected: /marvin/tests/smoke/test_primary_storage.py
   Intermitten failure detected: /marvin/tests/smoke/test_public_ip_range.py
   Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py
   Intermitten failure detected: /marvin/tests/smoke/test_templates.py
   Intermitten failure detected: /marvin/tests/smoke/test_usage.py
   Intermitten failure detected: /marvin/tests/smoke/test_vm_life_cycle.py
   Intermitten failure detected: /marvin/tests/smoke/test_volumes.py
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py
   Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 58 look OK, 9 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_01_add_primary_storage_disabled_host | `Error` | 0.71 | 
test_primary_storage.py
   test_01_primary_storage_nfs | `Error` | 0.11 | test_primary_storage.py
   ContextSuite context=TestStorageTags>:setup | `Error` | 0.19 | 
test_primary_storage.py
   test_02_list_snapshots_with_removed_data_store | `Error` | 1.15 | 
test_snapshots.py
   test_04_extract_template | `Failure` | 128.28 | test_templates.py
   ContextSuite context=TestISOUsage>:setup | `Error` | 0.00 | test_usage.py
   test_08_migrate_vm | `Error` | 15.71 | test_vm_life_cycle.py
   test_06_download_detached_volume | `Failure` | 137.56 | test_volumes.py
   test_04_rvpc_network_garbage_collector_nics | `Failure` | 448.41 | 
test_vpc_redundant.py
   test_01_cancel_host_maintenace_with_no_migration_jobs | `Failure` | 0.09 | 
test_host_maintenance.py
   test_02_cancel_host_maintenace_with_migration_jobs | `Error` | 2.23 | 
test_host_maintenance.py
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 2.42 | 
test_hostha_kvm.py
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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 

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-374233841
 
 
   @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-374233705
 
 
   @blueorangutan test


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-374216201
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1790


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-374194408
 
 
   @blueorangutan package


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-374194467
 
 
   @rafaelweingartner a Jenkins job has been kicked to build packages. I'll 
keep you posted as I make progress.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

nitin-maharana commented on a change in pull request #2486: [CLOUDSTACK-10323] 
Allow changing disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#discussion_r175391456
 
 

 ##
 File path: server/src/main/java/com/cloud/storage/VolumeApiServiceImpl.java
 ##
 @@ -2097,26 +2079,102 @@ public Volume migrateVolume(MigrateVolumeCmd cmd) {
 }
 }
 
-return orchestrateMigrateVolume(vol.getId(), destPool.getId(), 
liveMigrateVolume);
+return orchestrateMigrateVolume(vol, destPool, liveMigrateVolume, 
newDiskOffering);
 }
 
-private Volume orchestrateMigrateVolume(long volumeId, long destPoolId, 
boolean liveMigrateVolume) {
-VolumeVO vol = _volsDao.findById(volumeId);
-assert (vol != null);
-StoragePool destPool = 
(StoragePool)dataStoreMgr.getDataStore(destPoolId, DataStoreRole.Primary);
-assert (destPool != null);
+/**
+ * Retrieve the new disk offering UUID that might be sent to replace the 
current one in the volume being migrated.
+ * If no disk offering UUID is provided we return null. Otherwise, we 
perform the following checks.
+ * 
 
 Review comment:
   Got it. Thanks.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on a change in pull request #2486: 
[CLOUDSTACK-10323] Allow changing disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#discussion_r175390104
 
 

 ##
 File path: server/src/main/java/com/cloud/storage/VolumeApiServiceImpl.java
 ##
 @@ -2097,26 +2079,102 @@ public Volume migrateVolume(MigrateVolumeCmd cmd) {
 }
 }
 
-return orchestrateMigrateVolume(vol.getId(), destPool.getId(), 
liveMigrateVolume);
+return orchestrateMigrateVolume(vol, destPool, liveMigrateVolume, 
newDiskOffering);
 }
 
-private Volume orchestrateMigrateVolume(long volumeId, long destPoolId, 
boolean liveMigrateVolume) {
-VolumeVO vol = _volsDao.findById(volumeId);
-assert (vol != null);
-StoragePool destPool = 
(StoragePool)dataStoreMgr.getDataStore(destPoolId, DataStoreRole.Primary);
-assert (destPool != null);
+/**
+ * Retrieve the new disk offering UUID that might be sent to replace the 
current one in the volume being migrated.
+ * If no disk offering UUID is provided we return null. Otherwise, we 
perform the following checks.
+ * 
 
 Review comment:
   It is not by mistake. It is on purpose to format the java documentation. 
Using them you are able to create javadocs as this one:
   
![javadoc](https://user-images.githubusercontent.com/4129005/37590952-a3137f44-2b48-11e8-9408-a32906dc0732.png)
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

nitin-maharana commented on a change in pull request #2486: [CLOUDSTACK-10323] 
Allow changing disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#discussion_r175389207
 
 

 ##
 File path: server/src/main/java/com/cloud/storage/VolumeApiServiceImpl.java
 ##
 @@ -2097,26 +2079,102 @@ public Volume migrateVolume(MigrateVolumeCmd cmd) {
 }
 }
 
-return orchestrateMigrateVolume(vol.getId(), destPool.getId(), 
liveMigrateVolume);
+return orchestrateMigrateVolume(vol, destPool, liveMigrateVolume, 
newDiskOffering);
 }
 
-private Volume orchestrateMigrateVolume(long volumeId, long destPoolId, 
boolean liveMigrateVolume) {
-VolumeVO vol = _volsDao.findById(volumeId);
-assert (vol != null);
-StoragePool destPool = 
(StoragePool)dataStoreMgr.getDataStore(destPoolId, DataStoreRole.Primary);
-assert (destPool != null);
+/**
+ * Retrieve the new disk offering UUID that might be sent to replace the 
current one in the volume being migrated.
+ * If no disk offering UUID is provided we return null. Otherwise, we 
perform the following checks.
+ * 
 
 Review comment:
   @rafaelweingartner, I think you have added few HTML tags by mistake here. 
Not sure if it was intended.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

nitin-maharana commented on a change in pull request #2486: [CLOUDSTACK-10323] 
Allow changing disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#discussion_r175389207
 
 

 ##
 File path: server/src/main/java/com/cloud/storage/VolumeApiServiceImpl.java
 ##
 @@ -2097,26 +2079,102 @@ public Volume migrateVolume(MigrateVolumeCmd cmd) {
 }
 }
 
-return orchestrateMigrateVolume(vol.getId(), destPool.getId(), 
liveMigrateVolume);
+return orchestrateMigrateVolume(vol, destPool, liveMigrateVolume, 
newDiskOffering);
 }
 
-private Volume orchestrateMigrateVolume(long volumeId, long destPoolId, 
boolean liveMigrateVolume) {
-VolumeVO vol = _volsDao.findById(volumeId);
-assert (vol != null);
-StoragePool destPool = 
(StoragePool)dataStoreMgr.getDataStore(destPoolId, DataStoreRole.Primary);
-assert (destPool != null);
+/**
+ * Retrieve the new disk offering UUID that might be sent to replace the 
current one in the volume being migrated.
+ * If no disk offering UUID is provided we return null. Otherwise, we 
perform the following checks.
+ * 
 
 Review comment:
   @rafaelweingartner, I think you have added few HTML tags by mistake here.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

nitin-maharana commented on a change in pull request #2486: [CLOUDSTACK-10323] 
Allow changing disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#discussion_r175389327
 
 

 ##
 File path: server/src/main/java/com/cloud/storage/VolumeApiServiceImpl.java
 ##
 @@ -2097,26 +2079,102 @@ public Volume migrateVolume(MigrateVolumeCmd cmd) {
 }
 }
 
-return orchestrateMigrateVolume(vol.getId(), destPool.getId(), 
liveMigrateVolume);
+return orchestrateMigrateVolume(vol, destPool, liveMigrateVolume, 
newDiskOffering);
 }
 
-private Volume orchestrateMigrateVolume(long volumeId, long destPoolId, 
boolean liveMigrateVolume) {
-VolumeVO vol = _volsDao.findById(volumeId);
-assert (vol != null);
-StoragePool destPool = 
(StoragePool)dataStoreMgr.getDataStore(destPoolId, DataStoreRole.Primary);
-assert (destPool != null);
+/**
+ * Retrieve the new disk offering UUID that might be sent to replace the 
current one in the volume being migrated.
+ * If no disk offering UUID is provided we return null. Otherwise, we 
perform the following checks.
+ * 
+ *  Is the disk offering UUID entered valid? If not, an  {@link 
InvalidParameterValueException} is thrown;
+ *  If the disk offering was already removed, we thrown an {@link 
InvalidParameterValueException} is thrown;
+ *  We then check if the user executing the operation has access to 
the given disk offering.
+ * 
+ *
+ * If all checks pass, we move forward returning the disk offering object.
+ */
+private DiskOfferingVO retrieveAndValidateNewDiskOffering(MigrateVolumeCmd 
cmd) {
+String newDiskOfferingUuid = cmd.getNewDiskOfferingUuid();
+if (org.apache.commons.lang.StringUtils.isBlank(newDiskOfferingUuid)) {
+return null;
+}
+DiskOfferingVO newDiskOffering = 
_diskOfferingDao.findByUuid(newDiskOfferingUuid);
+if (newDiskOffering == null) {
+throw new InvalidParameterValueException(String.format("The disk 
offering informed is not valid [id=%s].", newDiskOfferingUuid));
+}
+if (newDiskOffering.getRemoved() != null) {
+throw new InvalidParameterValueException(String.format("We cannot 
assign a removed disk offering [id=%s] to a volume. ", 
newDiskOffering.getUuid()));
+}
+Account caller = CallContext.current().getCallingAccount();
+_accountMgr.checkAccess(caller, newDiskOffering);
+return newDiskOffering;
+}
+
+/**
+ * Performs the validations required for replacing the disk offering while 
migrating the volume of storage. If no new disk offering is provided, we do not 
execute any validation.
+ * If a disk offering is informed, we then proceed with the following 
checks.
+ * 
 
 Review comment:
   Same here.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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 

[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-16 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

DaanHoogland commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373681628
 
 
   thanks @rafaelweingartner , didn't notice the relation


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-16 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373676101
 
 
   @DaanHoogland now everything is ok again.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-16 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373640788
 
 
   @blueorangutan test


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-16 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373640898
 
 
   @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-16 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373633354
 
 
   @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-16 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373633268
 
 
   @blueorangutan test


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-16 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373371916
 
 
   @blueorangutan test


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373391397
 
 
   Yes. However, that is a consequence of the last merge and is fixed with: 
#2491


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

DaanHoogland commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373391096
 
 
   debian packaging failed and so did jenkins and travis!


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373371916
 
 
   @blueorangutan test


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373371964
 
 
   @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373354280
 
 
   Packaging result: ✔centos6 ✔centos7 ✖debian. JID-1781


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373348135
 
 
   @blueorangutan package


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373348238
 
 
   @borisstoyanov a Jenkins job has been kicked to build packages. I'll keep 
you posted as I make progress.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373338067
 
 
   Did you pushed your changes to your branch in the remote repository?
   I am checking your branch, but there is no new commit there.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373336567
 
 
   I'm not sure I'm doing this right.. but git says there's nothing to 
compare.. 
   ![screen shot 2018-03-15 at 12 51 
51](https://user-images.githubusercontent.com/13551960/37459115-c621161e-284f-11e8-8e42-c28590568c96.png)
   any idea? @rafaelweingartner 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373328490
 
 
   Thanks!
   You can open a PR against my branch, then I can merge it here.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373318892
 
 
   @rafaelweingartner I've created a marvin test but I'm not able to push to 
your repo. How can I contribute?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-14 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373196667
 
 
   Trillian test result (tid-2363)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 31355 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2486-t2363-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_public_ip_range.py
   Intermitten failure detected: /marvin/tests/smoke/test_ssvm.py
   Intermitten failure detected: /marvin/tests/smoke/test_templates.py
   Intermitten failure detected: /marvin/tests/smoke/test_usage.py
   Intermitten failure detected: /marvin/tests/smoke/test_volumes.py
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 62 look OK, 5 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_04_extract_template | `Failure` | 128.33 | test_templates.py
   ContextSuite context=TestISOUsage>:setup | `Error` | 0.00 | test_usage.py
   test_06_download_detached_volume | `Failure` | 137.59 | test_volumes.py
   test_01_redundant_vpc_site2site_vpn | `Failure` | 325.32 | test_vpc_vpn.py
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 0.45 | 
test_hostha_kvm.py
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-14 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373018087
 
 
   @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-14 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373017935
 
 
   @blueorangutan test


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-14 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373013562
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1777


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-14 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373002785
 
 
   @borisstoyanov a Jenkins job has been kicked to build packages. I'll keep 
you posted as I make progress.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-14 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373002801
 
 
   ok @rafaelweingartner, let me run some tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-14 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373002653
 
 
   @blueorangutan package


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-14 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing 
disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-372999216
 
 
   I added unit test for the code I changed. I was not planning to create a 
Marvin tests though.
   If you guys think it is a requirement, I can look into it.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-14 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk 
offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-372998708
 
 
   thanks for this PR @rafaelweingartner, are you looking into adding a marvin 
tests for this ?
   I'll wait on your response and kick the smoketests.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)


[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.

2018-03-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-10323:
-

rafaelweingartner opened a new pull request #2486: [CLOUDSTACK-10323] Allow 
changing disk offering during volume migration 
URL: https://github.com/apache/cloudstack/pull/2486
 
 
   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.
   
   Attached is a screenshot to show how the migrate option will look like:
   
![changeintheui](https://user-images.githubusercontent.com/4129005/37377238-729855d2-2707-11e8-8870-9c50ba614b20.png)
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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