[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16455523#comment-16455523 ] ASF subversion and git services commented on CLOUDSTACK-10323: -- Commit d6cbd774b76a044efbdbc531acd5c8c1925cc1d2 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=d6cbd77 ] [CLOUDSTACK-10323] Allow changing disk offering during volume migration (#2486) * [CLOUDSTACK-10323] Allow changing disk offering during volume migration This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), which provided root admins an override mechanism to move volumes between storage systems types (local/shared) even when the disk offering would not allow such operation. To complete the work, we will now provide a way for administrators to enter a new disk offering that can reflect the new placement of the volume. We will add an extra parameter to allow the root admin inform a new disk offering for the volume. Therefore, when the volume is being migrated, it will be possible to replace the disk offering to reflect the new placement of the volume. The API method will have the following parameters: * storageid (required) * volumeid (required) * livemigrate(optional) * newdiskofferingid (optional) – this is the new parameter The expected behavior is the following: * If “newdiskofferingid” is not provided the current behavior is maintained. Override mechanism will also keep working as we have seen so far. * If the “newdiskofferingid” is provided by the admin, we will execute the following checks ** new disk offering mode (local/shared) must match the target storage mode. If it does not match, an exception will be thrown and the operator will receive a message indicating the problem. ** we will check if the new disk offering tags match the target storage tags. If it does not match, an exception will be thrown and the operator will receive a message indicating the problem. ** check if the target storage has the capacity for the new volume. If it does not have enough space, then an exception is thrown and the operator will receive a message indicating the problem. ** check if the size of the volume is the same as the size of the new disk offering. If it is not the same, we will ALLOW the change of the service offering, and a warning message will be logged. We execute the change of the Disk offering as soon as the migration of the volume finishes. Therefore, if an error happens during the migration and the volume remains in the original storage system, the disk offering will keep reflecting this situation. * Code formatting * Adding a test to cover migration with new disk offering (#4) * Adding a test to cover migration with new disk offering * Update test_volumes.py * Update test_volumes.py * fix test_11_migrate_volume_and_change_offering * Fix typo in Java doc > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > *
[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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. > *
[jira] [Updated] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner updated CLOUDSTACK-10323: Status: Reviewable (was: In Progress) > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10323. - Resolution: Fixed Fix Version/s: 4.12 > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10240) ACS cannot migrate a volume from local to shared storage (for XenServer)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16455526#comment-16455526 ] ASF subversion and git services commented on CLOUDSTACK-10240: -- 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 > ACS cannot migrate a volume from local to shared storage (for XenServer) > > > Key: CLOUDSTACK-10240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10240 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > CloudStack is logically restricting the migration of local storages to shared > storage and vice versa. This restriction is a logical one and can be removed > for XenServer deployments. Therefore, we will enable migration of volumes > between local-shared storages in XenServers independently of their service > offering. This will work as an override mechanism to the disk offering used > by volumes. If administrators want to migrate local volumes to a shared > storage, they should be able to do so (the hypervisor already allows that). > The same the other way around. -- 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.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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()))
{
+thr
[jira] [Commented] (CLOUDSTACK-9975) Allow customizing system VM templates for SSVM and Console Proxy
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454816#comment-16454816 ] ASF GitHub Bot commented on CLOUDSTACK-9975: GabrielBrascher commented on issue #2275: CLOUDSTACK-9975: Allow customizing system VM templates for SSVM and Console Proxy URL: https://github.com/apache/cloudstack/pull/2275#issuecomment-384776794 Hi @rhtyd, sorry for the delay on this one. Unfortunately, that parameter (router.xxx) changes only router templates. At least that is what happened when I tested last time. Also, I looked at the code, and right now that parameter is not used to select SSVMs and console proxy templates. 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 > Allow customizing system VM templates for SSVM and Console Proxy > > > Key: CLOUDSTACK-9975 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9975 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Gabriel Beims Bräscher >Assignee: Gabriel Beims Bräscher >Priority: Minor > > Currently, it is only possible to change the template used by virtual > routers, but other system VMs do not have the same feature. The virtual > router template is configured according to the respective global settings > parameters: router.template.hyperv, router.template.kvm, router.template.lxc, > router.template.xenserver, router.template.ovm, router.template.vmware. > This ticket proposes the configuration of templates for storage system VMs > (SSVMs) and console proxy system VMs with parameters similar with the virtual > router template configuration: ssvm.template. and > consoleproxy.template. > If a parameter is null then it keeps the current flow for that scenario > (systemvm/virtualization tool). > This proposal allows users to customize virtual machines templates according > to specific needs of each system VM. This feature was useful in a practical > scenario where it was necessary to perform some changes for the console proxy > system VM template. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9975) Allow customizing system VM templates for SSVM and Console Proxy
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454815#comment-16454815 ] ASF GitHub Bot commented on CLOUDSTACK-9975: GabrielBrascher commented on issue #2275: CLOUDSTACK-9975: Allow customizing system VM templates for SSVM and Console Proxy URL: https://github.com/apache/cloudstack/pull/2275#issuecomment-384776794 Hi @rhtyd, sorry for the delay on this one. Unfortunately, that parameter (“”) changes only router templates. At least that is what happened when I tested last time. Also, I looked at the code, and right now that parameter is not used to select SSVMs and console proxy templates. 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 > Allow customizing system VM templates for SSVM and Console Proxy > > > Key: CLOUDSTACK-9975 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9975 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Gabriel Beims Bräscher >Assignee: Gabriel Beims Bräscher >Priority: Minor > > Currently, it is only possible to change the template used by virtual > routers, but other system VMs do not have the same feature. The virtual > router template is configured according to the respective global settings > parameters: router.template.hyperv, router.template.kvm, router.template.lxc, > router.template.xenserver, router.template.ovm, router.template.vmware. > This ticket proposes the configuration of templates for storage system VMs > (SSVMs) and console proxy system VMs with parameters similar with the virtual > router template configuration: ssvm.template. and > consoleproxy.template. > If a parameter is null then it keeps the current flow for that scenario > (systemvm/virtualization tool). > This proposal allows users to customize virtual machines templates according > to specific needs of each system VM. This feature was useful in a practical > scenario where it was necessary to perform some changes for the console proxy > system VM template. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9975) Allow customizing system VM templates for SSVM and Console Proxy
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454814#comment-16454814 ] ASF GitHub Bot commented on CLOUDSTACK-9975: GabrielBrascher commented on issue #2275: CLOUDSTACK-9975: Allow customizing system VM templates for SSVM and Console Proxy URL: https://github.com/apache/cloudstack/pull/2275#issuecomment-384776794 Hi @rhtyd, sorry for the delay on this one. Unfortunately, without this proposal, it does change only router template. At least at the time that I had to perform this changes. 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 > Allow customizing system VM templates for SSVM and Console Proxy > > > Key: CLOUDSTACK-9975 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9975 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Gabriel Beims Bräscher >Assignee: Gabriel Beims Bräscher >Priority: Minor > > Currently, it is only possible to change the template used by virtual > routers, but other system VMs do not have the same feature. The virtual > router template is configured according to the respective global settings > parameters: router.template.hyperv, router.template.kvm, router.template.lxc, > router.template.xenserver, router.template.ovm, router.template.vmware. > This ticket proposes the configuration of templates for storage system VMs > (SSVMs) and console proxy system VMs with parameters similar with the virtual > router template configuration: ssvm.template. and > consoleproxy.template. > If a parameter is null then it keeps the current flow for that scenario > (systemvm/virtualization tool). > This proposal allows users to customize virtual machines templates according > to specific needs of each system VM. This feature was useful in a practical > scenario where it was necessary to perform some changes for the console proxy > system VM template. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9975) Allow customizing system VM templates for SSVM and Console Proxy
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454807#comment-16454807 ] ASF GitHub Bot commented on CLOUDSTACK-9975: GabrielBrascher commented on issue #2275: CLOUDSTACK-9975: Allow customizing system VM templates for SSVM and Console Proxy URL: https://github.com/apache/cloudstack/pull/2275#issuecomment-384776794 Hi @rhtyd, sorry for the delay on this one. Unfortunately, it does change only router template. At least at the time that I had to perform this changes. 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 > Allow customizing system VM templates for SSVM and Console Proxy > > > Key: CLOUDSTACK-9975 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9975 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Gabriel Beims Bräscher >Assignee: Gabriel Beims Bräscher >Priority: Minor > > Currently, it is only possible to change the template used by virtual > routers, but other system VMs do not have the same feature. The virtual > router template is configured according to the respective global settings > parameters: router.template.hyperv, router.template.kvm, router.template.lxc, > router.template.xenserver, router.template.ovm, router.template.vmware. > This ticket proposes the configuration of templates for storage system VMs > (SSVMs) and console proxy system VMs with parameters similar with the virtual > router template configuration: ssvm.template. and > consoleproxy.template. > If a parameter is null then it keeps the current flow for that scenario > (systemvm/virtualization tool). > This proposal allows users to customize virtual machines templates according > to specific needs of each system VM. This feature was useful in a practical > scenario where it was necessary to perform some changes for the console proxy > system VM template. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-7982) Storage live migration support for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454753#comment-16454753 ] ASF GitHub Bot commented on CLOUDSTACK-7982: GabrielBrascher commented on issue #1709: CLOUDSTACK-7982: KVM live migration with local storage URL: https://github.com/apache/cloudstack/pull/1709#issuecomment-384764252 @marcaurele Do you need any help with this PR? Please ping me if necessary. 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 > Storage live migration support for KVM > -- > > Key: CLOUDSTACK-7982 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7982 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Marc-Aurèle Brothier >Priority: Major > Fix For: Future > > > Currently it supports Xenserver, Vmware, Hyper-V, but not KVM. > We need to add the implementation for KVM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9677) Swift Storage Policy support for Secondary Storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454417#comment-16454417 ] ASF GitHub Bot commented on CLOUDSTACK-9677: pdube commented on issue #2412: CLOUDSTACK-9677: Adding storage policy support for swift as secondary… URL: https://github.com/apache/cloudstack/pull/2412#issuecomment-384691609 Thanks @khos2ow 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 > Swift Storage Policy support for Secondary Storage > -- > > Key: CLOUDSTACK-9677 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9677 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Patrick D. >Assignee: Patrick D. >Priority: Major > Fix For: 4.11.1.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454217#comment-16454217 ] ASF GitHub Bot commented on CLOUDSTACK-4045: rafaelweingartner commented on issue #2382: CLOUDSTACK-4045 IP address acquired with associateIpAddress is marked as source NAT URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-384644724 @DaanHoogland are you happy with the tests result? Or, would you like to execute them 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 > IP address acquired with associateIpAddress is marked as source NAT, causing > disassociateIpAddress to fail later > > > Key: CLOUDSTACK-4045 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0 >Reporter: Murali Reddy >Assignee: Henko Holtzhausen >Priority: Major > Fix For: Future > > > When you can create network, network is in allocated state. when network is > implemented CloudStack implicitly should acquire a public IP for source nat. > But there is assumption that first IP this is associated with network is > always for source NAT IP. So when you do > 1. create network (network is in allocated state) > 2. acquire a public IP and associate with the network > 3. disassociate ip address > #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. > For users this is counter-intutive because when a IP is acquired, he/she > should be able to release it as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454214#comment-16454214 ] ASF GitHub Bot commented on CLOUDSTACK-4045: rafaelweingartner commented on issue #2382: CLOUDSTACK-4045 IP address acquired with associateIpAddress is marked as source NAT URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-384644414 @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 > IP address acquired with associateIpAddress is marked as source NAT, causing > disassociateIpAddress to fail later > > > Key: CLOUDSTACK-4045 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0 >Reporter: Murali Reddy >Assignee: Henko Holtzhausen >Priority: Major > Fix For: Future > > > When you can create network, network is in allocated state. when network is > implemented CloudStack implicitly should acquire a public IP for source nat. > But there is assumption that first IP this is associated with network is > always for source NAT IP. So when you do > 1. create network (network is in allocated state) > 2. acquire a public IP and associate with the network > 3. disassociate ip address > #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. > For users this is counter-intutive because when a IP is acquired, he/she > should be able to release it as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454208#comment-16454208
]
ASF GitHub Bot commented on CLOUDSTACK-4045:
rafaelweingartner commented on a change in pull request #2382: CLOUDSTACK-4045
IP address acquired with associateIpAddress is marked as source NAT
URL: https://github.com/apache/cloudstack/pull/2382#discussion_r184392158
##
File path: server/src/main/java/com/cloud/network/IpAddressManagerImpl.java
##
@@ -1417,6 +1408,25 @@ public IPAddressVO associateIPToGuestNetwork(long ipId,
long networkId, boolean
}
}
+protected boolean isSourceNatAvailableForNetwork(Account owner,
IPAddressVO ipToAssoc, Network network) {
Review comment:
To make it perfect a Java documentation describing when an IP is considered
source NAT would be welcome.
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
> IP address acquired with associateIpAddress is marked as source NAT, causing
> disassociateIpAddress to fail later
>
>
> Key: CLOUDSTACK-4045
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0
>Reporter: Murali Reddy
>Assignee: Henko Holtzhausen
>Priority: Major
> Fix For: Future
>
>
> When you can create network, network is in allocated state. when network is
> implemented CloudStack implicitly should acquire a public IP for source nat.
> But there is assumption that first IP this is associated with network is
> always for source NAT IP. So when you do
> 1. create network (network is in allocated state)
> 2. acquire a public IP and associate with the network
> 3. disassociate ip address
> #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT.
> For users this is counter-intutive because when a IP is acquired, he/she
> should be able to release it as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10223) Snapshots are not getting deleted when domain is deleted
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454198#comment-16454198
]
ASF GitHub Bot commented on CLOUDSTACK-10223:
-
rafaelweingartner commented on a change in pull request #2399: CLOUDSTACK-10223
delete snapshots when deleting domain
URL: https://github.com/apache/cloudstack/pull/2399#discussion_r184390757
##
File path:
server/src/main/java/com/cloud/storage/snapshot/SnapshotManagerImpl.java
##
@@ -715,7 +715,7 @@ public String getSecondaryStorageURL(SnapshotVO snapshot) {
@Override
public boolean deleteSnapshotDirsForAccount(long accountId) {
-List volumes = _volsDao.findByAccount(accountId);
+List volumes =
_volsDao.findIncludingRemovedByAccount(accountId);
Review comment:
Sorry my lack of knowledge here. Do snapshots have an entry in the `volumes`
table?
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
> Snapshots are not getting deleted when domain is deleted
>
>
> Key: CLOUDSTACK-10223
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10223
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Sowjanya_Patha
>Priority: Minor
>
> After domain deletion, snapshot taken by the domain remains undeleted.
> Steps to reproduce:
> ---
> 1. Create a test domain
> 2. Create test account with admin privileges.
> 3. Login as "test" acoount.
> 4. Create 3 instances - few having root disk and rest with root and data
> disks both.
> 5. For 2 instances take snapshots of root and data disks
> 6. Expunge above instances from ACP UI.
> 7. Make sure that those vm's should not be shown in ACP UI.
> 8. Login as root user again
> 9. Delete the test account
> 10. Delete the test domain
> Snapshots taken for root volume in step 5 are not deleted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10363) Inconsistent "getXXX" and "listXXX" method names.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454197#comment-16454197
]
ASF GitHub Bot commented on CLOUDSTACK-10363:
-
BruceKuiLiu commented on issue #2599: CLOUDSTACK-10363: Change method names.
URL: https://github.com/apache/cloudstack/pull/2599#issuecomment-384642781
@rafaelweingartner 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
> Inconsistent "getXXX" and "listXXX" method names.
> -
>
> Key: CLOUDSTACK-10363
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10363
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: KuiLIU
>Priority: Major
>
> The following methods are not direct getter or list.
> They try to find the target objects with the related arguments.
> So that, renaming them as "findXXX" should be more intuitive.
> {code:java}
> //cloudstack/plugins/network-elements/ovs/src/main/java/com/cloud/network/ovs/dao/OvsTunnelInterfaceDaoImpl.java
> @Override
> public OvsTunnelInterfaceVO getByHostAndLabel(long hostId, String label) {
> SearchCriteria sc = hostAndLabelSearch.create();
> sc.setParameters("host_id", hostId);
> sc.setParameters("label", label);
> return findOneBy(sc);
> }
> //cloudstack/services/secondary-storage/controller/src/main/java/org/apache/cloudstack/secondarystorage/PremiumSecondaryStorageManagerImpl.java
> private List listActiveCommands(long dcId, Date
> cutTime) {
> SearchCriteria sc = activeCommandSearch.create();
> sc.setParameters("created", cutTime);
> sc.setJoinParameters("hostSearch", "dc", dcId);
> sc.setJoinParameters("hostSearch", "status", Status.Up);
> return _cmdExecLogDao.search(sc, null);
> }
> //cloudstack/framework/jobs/src/main/java/org/apache/cloudstack/framework/jobs/impl/AsyncJobManagerImpl.java
> private AsyncJobDispatcher getWakeupDispatcher(AsyncJob job) {
> if (_jobDispatchers != null) {
> List joinRecords =
> _joinMapDao.listJoinRecords(job.getId());
> if (joinRecords.size() > 0) {
> AsyncJobJoinMapVO joinRecord = joinRecords.get(0);
> for (AsyncJobDispatcher dispatcher : _jobDispatchers) {
> if
> (dispatcher.getName().equals(joinRecord.getWakeupDispatcher()))
> return dispatcher;
> }
> } else {
> s_logger.warn("job-" + job.getId() + " is scheduled for
> wakeup run, but there is no joining info anymore");
> }
> }
> return null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10254) Require checkstyle to verify package names against directory structure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454193#comment-16454193 ] ASF subversion and git services commented on CLOUDSTACK-10254: -- Commit 46bd94c6a206c6ccc8832369d4726b5b17620208 in cloudstack's branch refs/heads/master from [~marcaurele] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=46bd94c ] [CLOUDSTACK-10254] checkstyle: add package name declaration validation (#2422) * checktyle: verify package name matches directory structure * fix new checkstyle findings on directory with package name mismatch > Require checkstyle to verify package names against directory structure > -- > > Key: CLOUDSTACK-10254 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10254 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Marc-Aurèle Brothier >Assignee: Marc-Aurèle Brothier >Priority: Major > Fix For: 4.12 > > > Enforce a new rule for checkstyle to verify that the java file location and > its package name match. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10254) Require checkstyle to verify package names against directory structure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10254. - Resolution: Fixed Fix Version/s: 4.12 > Require checkstyle to verify package names against directory structure > -- > > Key: CLOUDSTACK-10254 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10254 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Marc-Aurèle Brothier >Assignee: Marc-Aurèle Brothier >Priority: Major > Fix For: 4.12 > > > Enforce a new rule for checkstyle to verify that the java file location and > its package name match. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10254) Require checkstyle to verify package names against directory structure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454192#comment-16454192 ] ASF GitHub Bot commented on CLOUDSTACK-10254: - rafaelweingartner closed pull request #2422: [CLOUDSTACK-10254] checkstyle: add package name declaration validation URL: https://github.com/apache/cloudstack/pull/2422 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/engine/api/src/main/java/org/apache/cloudstack/engine/subsystem/api/storage/disktype/QCOW2.java b/engine/api/src/main/java/org/apache/cloudstack/engine/subsystem/api/storage/disktype/QCOW2.java deleted file mode 100644 index b248758bc12..000 --- a/engine/api/src/main/java/org/apache/cloudstack/engine/subsystem/api/storage/disktype/QCOW2.java +++ /dev/null @@ -1,16 +0,0 @@ -// Licensed to the Apache Software Foundation (ASF) under one -// or more contributor license agreements. See the NOTICE file -// distributed with this work for additional information -// regarding copyright ownership. The ASF licenses this file -// to you under the Apache License, Version 2.0 (the -// "License"); you may not use this file except in compliance -// with the License. You may obtain a copy of the License at -// -// http://www.apache.org/licenses/LICENSE-2.0 -// -// Unless required by applicable law or agreed to in writing, -// software distributed under the License is distributed on an -// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -// KIND, either express or implied. See the License for the -// specific language governing permissions and limitations -// under the License. diff --git a/engine/api/src/main/java/org/apache/cloudstack/engine/subsystem/api/storage/disktype/Unknown.java b/engine/api/src/main/java/org/apache/cloudstack/engine/subsystem/api/storage/disktype/Unknown.java deleted file mode 100644 index b248758bc12..000 --- a/engine/api/src/main/java/org/apache/cloudstack/engine/subsystem/api/storage/disktype/Unknown.java +++ /dev/null @@ -1,16 +0,0 @@ -// Licensed to the Apache Software Foundation (ASF) under one -// or more contributor license agreements. See the NOTICE file -// distributed with this work for additional information -// regarding copyright ownership. The ASF licenses this file -// to you under the Apache License, Version 2.0 (the -// "License"); you may not use this file except in compliance -// with the License. You may obtain a copy of the License at -// -// http://www.apache.org/licenses/LICENSE-2.0 -// -// Unless required by applicable law or agreed to in writing, -// software distributed under the License is distributed on an -// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -// KIND, either express or implied. See the License for the -// specific language governing permissions and limitations -// under the License. diff --git a/engine/api/src/main/java/org/apache/cloudstack/engine/subsystem/api/storage/disktype/VHD.java b/engine/api/src/main/java/org/apache/cloudstack/engine/subsystem/api/storage/disktype/VHD.java deleted file mode 100644 index b248758bc12..000 --- a/engine/api/src/main/java/org/apache/cloudstack/engine/subsystem/api/storage/disktype/VHD.java +++ /dev/null @@ -1,16 +0,0 @@ -// Licensed to the Apache Software Foundation (ASF) under one -// or more contributor license agreements. See the NOTICE file -// distributed with this work for additional information -// regarding copyright ownership. The ASF licenses this file -// to you under the Apache License, Version 2.0 (the -// "License"); you may not use this file except in compliance -// with the License. You may obtain a copy of the License at -// -// http://www.apache.org/licenses/LICENSE-2.0 -// -// Unless required by applicable law or agreed to in writing, -// software distributed under the License is distributed on an -// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -// KIND, either express or implied. See the License for the -// specific language governing permissions and limitations -// under the License. diff --git a/engine/api/src/main/java/org/apache/cloudstack/engine/subsystem/api/storage/disktype/VHDX.java b/engine/api/src/main/java/org/apache/cloudstack/engine/subsystem/api/storage/disktype/VHDX.java deleted file mode 100644 index b248758bc12..000 --- a/engine/api/src/main/java/org/apache/cloudstack/engine/subsystem/api/storage/disktype/VHDX.java +++ /dev/null @@ -1,16 +0,0 @@ -// Licensed to the Apache Software Foundation (ASF) under one -// or more contributor license agreements. See the NOTICE file -// distributed with this work for additional information -// regarding copyright ownership. The ASF l
[jira] [Commented] (CLOUDSTACK-10362) Inconsistent method names
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454184#comment-16454184
]
ASF GitHub Bot commented on CLOUDSTACK-10362:
-
BruceKuiLiu opened a new pull request #2600: CLOUDSTACK-10362: Change the
"getXXX" method names to "isXXX".
URL: https://github.com/apache/cloudstack/pull/2600
These Boolean-return methods are named "getXXX",
but other Boolean-return methods are named "isXXX", such as the following
two methods.
They will return boolean values, rename them as "isXXX" should be more clear
than "getXXX".
api/src/main/java/org/apache/cloudstack/api/command/admin/vlan/ListVlanIpRangesCmd.java
```
public Boolean getForVirtualNetwork() {
return forVirtualNetwork;
}
```
api/src/main/java/org/apache/cloudstack/api/command/user/address/ListPublicIpAddressesCmd.java
```
public Boolean isForVirtualNetwork() {
return forVirtualNetwork;
}
```
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
> Inconsistent method names
> -
>
> Key: CLOUDSTACK-10362
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10362
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: KuiLIU
>Priority: Major
>
> Some Boolean-return methods are named "getXXX",
> but other Boolean-return methods are named "isXXX", such as the following two
> methods.
> They will return boolean values, rename them as "isXXX" should be more clear
> than "getXXX".
> api/src/main/java/org/apache/cloudstack/api/command/admin/vlan/ListVlanIpRangesCmd.java
> {code:java}
> public Boolean getForVirtualNetwork() {
> return forVirtualNetwork;
> }
> {code}
> api/src/main/java/org/apache/cloudstack/api/command/user/address/ListPublicIpAddressesCmd.java
> {code:java}
> public Boolean isForVirtualNetwork() {
> return forVirtualNetwork;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10364) Inconsiste "setXXX" method names.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454181#comment-16454181
]
ASF GitHub Bot commented on CLOUDSTACK-10364:
-
BruceKuiLiu opened a new pull request #2601: CLOUDSTACK-10364: Change the
"setXXX" method names to "getXXX".
URL: https://github.com/apache/cloudstack/pull/2601
The two methods are named as "setXXX",
actually, they are not setter but getter.
Thus, they should be renamed as "getXXX".
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
> Inconsiste "setXXX" method names.
> -
>
> Key: CLOUDSTACK-10364
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10364
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: KuiLIU
>Priority: Major
>
> The following two methods are named as "setXXX",
> actually, they are not setter but getter.
> Thus, they should be renamed as "getXXX".
> {code:java}
> private String setVnetBrName(String pifName, String vnetId) {
> return "br" + pifName + "-" + vnetId;
> }
> private String setVxnetBrName(String pifName, String vnetId) {
> return "brvx-" + vnetId;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10365) Inconsistent boolean-related method names
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454180#comment-16454180
]
ASF GitHub Bot commented on CLOUDSTACK-10365:
-
BruceKuiLiu opened a new pull request #2602: CLOUDSTACK-10365: Change the
"getXXX" boolean-related method names to…
URL: https://github.com/apache/cloudstack/pull/2602
… "isXXX".
These boolean-return methods are named as "getXXX".
Other boolean-return methods are named as "isXXX".
Considering there methods will return boolean values, it should be more
clear and consistent to rename them as "isXXX".
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
> Inconsistent boolean-related method names
> -
>
> Key: CLOUDSTACK-10365
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10365
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: KuiLIU
>Priority: Major
>
> These boolean-return methods are named as "getXXX".
> Other boolean-return methods are named as "isXXX".
> Considering there methods will return boolean values, it should be more clear
> to rename them as "isXXX".
> {code:java}
> public boolean getEnableRRS() {
> return enableRRS;
> }
> public boolean getEnableRRS() {
> return enableRRS;
> }
> public boolean getShrinkOk() {
> return shrinkOk;
> }
>
> public boolean getSourceNat() {
> return sourceNat;
> }
>
> public boolean getInternalLb() {
> return internalLb;
> }
>
> public boolean getOfferHA() {
> return offerHA;
> }
>
> public boolean getVolatileVm() {
> return volatileVm;
> }
>
> public boolean getIsUserDefined() {
> return isUserDefined;
> }
>
> public boolean getEnablePassword() {
> return enablePassword;
> }
>
> public boolean getEnableSshKey() {
> return enableSshKey;
> }
>
> public boolean getUuidTranslation() {
> return _doUuidTranslation;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10362) Inconsistent method names
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454057#comment-16454057
]
ASF GitHub Bot commented on CLOUDSTACK-10362:
-
rafaelweingartner commented on issue #2599: CLOUDSTACK-10362, CLOUDSTACK-10363,
CLOUDSTACK-10364, CLOUDSTACK-10365 Change method names.
URL: https://github.com/apache/cloudstack/pull/2599#issuecomment-384638539
@BruceKuiLiu even though everything seems to be ok here, I actually likes
the three separated PRs. It reduced the scope for reviewers.
If you are going to proceed only with this one, can you please close the
others? The choice is yours.
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
> Inconsistent method names
> -
>
> Key: CLOUDSTACK-10362
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10362
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: KuiLIU
>Priority: Major
>
> Some Boolean-return methods are named "getXXX",
> but other Boolean-return methods are named "isXXX", such as the following two
> methods.
> They will return boolean values, rename them as "isXXX" should be more clear
> than "getXXX".
> api/src/main/java/org/apache/cloudstack/api/command/admin/vlan/ListVlanIpRangesCmd.java
> {code:java}
> public Boolean getForVirtualNetwork() {
> return forVirtualNetwork;
> }
> {code}
> api/src/main/java/org/apache/cloudstack/api/command/user/address/ListPublicIpAddressesCmd.java
> {code:java}
> public Boolean isForVirtualNetwork() {
> return forVirtualNetwork;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10289) Config drive - Metadata leaking internal ids
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454022#comment-16454022
]
ASF subversion and git services commented on CLOUDSTACK-10289:
--
Commit b3c22df71d0ec3c29fbe37dc3c9812353c1685d9 in cloudstack's branch
refs/heads/master from [~rafaelweingartner]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=b3c22df ]
Forward merge branch '4.11' to master
ConfigDrive fixes: CLOUDSTACK-10288, CLOUDSTACK-10289 (#2566)
CLOUDSTACK-9677: Adding storage policy support for swift as secondary
storage (#2412)
> Config drive - Metadata leaking internal ids
>
>
> Key: CLOUDSTACK-10289
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10289
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.11.0.0
>Reporter: Rohit Yadav
>Assignee: Frank Maximus
>Priority: Major
> Fix For: 4.11.1.0
>
>
> Metadata on config drive looks like this, which is different from what
> routervm userdata looks like. Leaking internal IDs:
> # for i in `ls`; do echo -n $i : ; cat $i; echo; done
> availability-zone.txt : zone1
> cloud-identifier.txt : CloudStack-\{af714831-9a23-4ee4-a415-984a6dae1c61}
> instance-id.txt : i-2-24-VM
> local-hostname.txt : i-2-24-VM
> service-offering.txt : Small Instance
> vm-id.txt : 24
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10288) Config drive - Usedata corruption when gzipped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454015#comment-16454015 ] ASF subversion and git services commented on CLOUDSTACK-10288: -- Commit 85203248a4bf8a4c09742ba1c4ae236ee008a15f in cloudstack's branch refs/heads/master from [~fmaximus] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=8520324 ] ConfigDrive fixes: CLOUDSTACK-10288, CLOUDSTACK-10289 (#2566) * CLOUDSTACK-10289: Config Drive Metadata: Use VM UUID instead of VM id * CLOUDSTACK-10288: Config Drive Userdata: support for binary userdata * CLOUDSTACK-10358: SSH keys are missing on Config Drive disk in some cases > Config drive - Usedata corruption when gzipped > --- > > Key: CLOUDSTACK-10288 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10288 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Rohit Yadav >Assignee: Frank Maximus >Priority: Major > Fix For: 4.11.1.0 > > > Should be able to create userdata via "echo hi | gzip | base64 -w0" and read > it back in VM via "mount -o loop /dev/sr1 /mnt/tmp; cat > /mnt/tmp/cloudstack/userdata/user_data.txt | gunzip" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10358) [ConfigDrive] SSH keys are missing on Config Drive disk in some cases
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454020#comment-16454020
]
ASF subversion and git services commented on CLOUDSTACK-10358:
--
Commit 85203248a4bf8a4c09742ba1c4ae236ee008a15f in cloudstack's branch
refs/heads/master from [~fmaximus]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=8520324 ]
ConfigDrive fixes: CLOUDSTACK-10288, CLOUDSTACK-10289 (#2566)
* CLOUDSTACK-10289: Config Drive Metadata: Use VM UUID instead of VM id
* CLOUDSTACK-10288: Config Drive Userdata: support for binary userdata
* CLOUDSTACK-10358: SSH keys are missing on Config Drive disk in some cases
> [ConfigDrive] SSH keys are missing on Config Drive disk in some cases
> -
>
> Key: CLOUDSTACK-10358
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10358
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.11.0.0
>Reporter: Frank Maximus
>Assignee: Frank Maximus
>Priority: Major
> Fix For: 4.11.1.0
>
>
> Following use case fails:
> {quote}*Given* a network offering with UserData provided by ConfigDrive
> *And* a network using that offering
> *When* I deploy a VM, specifying a keypair
> *Then* the public-keys.txt file on the config drive disk attached to the vm
> contains the public key
> {quote}
> Actual behaviour:
> bq. public-keys.txt is missing
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9677) Swift Storage Policy support for Secondary Storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454023#comment-16454023 ] ASF subversion and git services commented on CLOUDSTACK-9677: - Commit b3c22df71d0ec3c29fbe37dc3c9812353c1685d9 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=b3c22df ] Forward merge branch '4.11' to master ConfigDrive fixes: CLOUDSTACK-10288, CLOUDSTACK-10289 (#2566) CLOUDSTACK-9677: Adding storage policy support for swift as secondary storage (#2412) > Swift Storage Policy support for Secondary Storage > -- > > Key: CLOUDSTACK-9677 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9677 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Patrick D. >Assignee: Patrick D. >Priority: Major > Fix For: 4.11.1.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10288) Config drive - Usedata corruption when gzipped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454021#comment-16454021 ] ASF subversion and git services commented on CLOUDSTACK-10288: -- Commit b3c22df71d0ec3c29fbe37dc3c9812353c1685d9 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=b3c22df ] Forward merge branch '4.11' to master ConfigDrive fixes: CLOUDSTACK-10288, CLOUDSTACK-10289 (#2566) CLOUDSTACK-9677: Adding storage policy support for swift as secondary storage (#2412) > Config drive - Usedata corruption when gzipped > --- > > Key: CLOUDSTACK-10288 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10288 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Rohit Yadav >Assignee: Frank Maximus >Priority: Major > Fix For: 4.11.1.0 > > > Should be able to create userdata via "echo hi | gzip | base64 -w0" and read > it back in VM via "mount -o loop /dev/sr1 /mnt/tmp; cat > /mnt/tmp/cloudstack/userdata/user_data.txt | gunzip" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10289) Config drive - Metadata leaking internal ids
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454018#comment-16454018
]
ASF subversion and git services commented on CLOUDSTACK-10289:
--
Commit 85203248a4bf8a4c09742ba1c4ae236ee008a15f in cloudstack's branch
refs/heads/master from [~fmaximus]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=8520324 ]
ConfigDrive fixes: CLOUDSTACK-10288, CLOUDSTACK-10289 (#2566)
* CLOUDSTACK-10289: Config Drive Metadata: Use VM UUID instead of VM id
* CLOUDSTACK-10288: Config Drive Userdata: support for binary userdata
* CLOUDSTACK-10358: SSH keys are missing on Config Drive disk in some cases
> Config drive - Metadata leaking internal ids
>
>
> Key: CLOUDSTACK-10289
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10289
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.11.0.0
>Reporter: Rohit Yadav
>Assignee: Frank Maximus
>Priority: Major
> Fix For: 4.11.1.0
>
>
> Metadata on config drive looks like this, which is different from what
> routervm userdata looks like. Leaking internal IDs:
> # for i in `ls`; do echo -n $i : ; cat $i; echo; done
> availability-zone.txt : zone1
> cloud-identifier.txt : CloudStack-\{af714831-9a23-4ee4-a415-984a6dae1c61}
> instance-id.txt : i-2-24-VM
> local-hostname.txt : i-2-24-VM
> service-offering.txt : Small Instance
> vm-id.txt : 24
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10289) Config drive - Metadata leaking internal ids
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454016#comment-16454016
]
ASF subversion and git services commented on CLOUDSTACK-10289:
--
Commit 85203248a4bf8a4c09742ba1c4ae236ee008a15f in cloudstack's branch
refs/heads/master from [~fmaximus]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=8520324 ]
ConfigDrive fixes: CLOUDSTACK-10288, CLOUDSTACK-10289 (#2566)
* CLOUDSTACK-10289: Config Drive Metadata: Use VM UUID instead of VM id
* CLOUDSTACK-10288: Config Drive Userdata: support for binary userdata
* CLOUDSTACK-10358: SSH keys are missing on Config Drive disk in some cases
> Config drive - Metadata leaking internal ids
>
>
> Key: CLOUDSTACK-10289
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10289
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.11.0.0
>Reporter: Rohit Yadav
>Assignee: Frank Maximus
>Priority: Major
> Fix For: 4.11.1.0
>
>
> Metadata on config drive looks like this, which is different from what
> routervm userdata looks like. Leaking internal IDs:
> # for i in `ls`; do echo -n $i : ; cat $i; echo; done
> availability-zone.txt : zone1
> cloud-identifier.txt : CloudStack-\{af714831-9a23-4ee4-a415-984a6dae1c61}
> instance-id.txt : i-2-24-VM
> local-hostname.txt : i-2-24-VM
> service-offering.txt : Small Instance
> vm-id.txt : 24
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9677) Swift Storage Policy support for Secondary Storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454014#comment-16454014 ] ASF subversion and git services commented on CLOUDSTACK-9677: - Commit b6d420bec3b4cb02651cffd43502ed880f100bef in cloudstack's branch refs/heads/master from [~kmoossavi] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=b6d420b ] CLOUDSTACK-9677: Adding storage policy support for swift as secondary storage (#2412) Original-Author: @pdube on PR Fixes #1830. > Swift Storage Policy support for Secondary Storage > -- > > Key: CLOUDSTACK-9677 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9677 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Patrick D. >Assignee: Patrick D. >Priority: Major > Fix For: 4.11.1.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10288) Config drive - Usedata corruption when gzipped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454019#comment-16454019 ] ASF subversion and git services commented on CLOUDSTACK-10288: -- Commit 85203248a4bf8a4c09742ba1c4ae236ee008a15f in cloudstack's branch refs/heads/master from [~fmaximus] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=8520324 ] ConfigDrive fixes: CLOUDSTACK-10288, CLOUDSTACK-10289 (#2566) * CLOUDSTACK-10289: Config Drive Metadata: Use VM UUID instead of VM id * CLOUDSTACK-10288: Config Drive Userdata: support for binary userdata * CLOUDSTACK-10358: SSH keys are missing on Config Drive disk in some cases > Config drive - Usedata corruption when gzipped > --- > > Key: CLOUDSTACK-10288 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10288 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Rohit Yadav >Assignee: Frank Maximus >Priority: Major > Fix For: 4.11.1.0 > > > Should be able to create userdata via "echo hi | gzip | base64 -w0" and read > it back in VM via "mount -o loop /dev/sr1 /mnt/tmp; cat > /mnt/tmp/cloudstack/userdata/user_data.txt | gunzip" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10289) Config drive - Metadata leaking internal ids
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner resolved CLOUDSTACK-10289.
-
Resolution: Fixed
Fix Version/s: 4.11.1.0
> Config drive - Metadata leaking internal ids
>
>
> Key: CLOUDSTACK-10289
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10289
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.11.0.0
>Reporter: Rohit Yadav
>Assignee: Frank Maximus
>Priority: Major
> Fix For: 4.11.1.0
>
>
> Metadata on config drive looks like this, which is different from what
> routervm userdata looks like. Leaking internal IDs:
> # for i in `ls`; do echo -n $i : ; cat $i; echo; done
> availability-zone.txt : zone1
> cloud-identifier.txt : CloudStack-\{af714831-9a23-4ee4-a415-984a6dae1c61}
> instance-id.txt : i-2-24-VM
> local-hostname.txt : i-2-24-VM
> service-offering.txt : Small Instance
> vm-id.txt : 24
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10358) [ConfigDrive] SSH keys are missing on Config Drive disk in some cases
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner resolved CLOUDSTACK-10358.
-
Resolution: Fixed
> [ConfigDrive] SSH keys are missing on Config Drive disk in some cases
> -
>
> Key: CLOUDSTACK-10358
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10358
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.11.0.0
>Reporter: Frank Maximus
>Assignee: Frank Maximus
>Priority: Major
> Fix For: 4.11.1.0
>
>
> Following use case fails:
> {quote}*Given* a network offering with UserData provided by ConfigDrive
> *And* a network using that offering
> *When* I deploy a VM, specifying a keypair
> *Then* the public-keys.txt file on the config drive disk attached to the vm
> contains the public key
> {quote}
> Actual behaviour:
> bq. public-keys.txt is missing
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10358) [ConfigDrive] SSH keys are missing on Config Drive disk in some cases
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454000#comment-16454000
]
ASF subversion and git services commented on CLOUDSTACK-10358:
--
Commit 85203248a4bf8a4c09742ba1c4ae236ee008a15f in cloudstack's branch
refs/heads/4.11 from [~fmaximus]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=8520324 ]
ConfigDrive fixes: CLOUDSTACK-10288, CLOUDSTACK-10289 (#2566)
* CLOUDSTACK-10289: Config Drive Metadata: Use VM UUID instead of VM id
* CLOUDSTACK-10288: Config Drive Userdata: support for binary userdata
* CLOUDSTACK-10358: SSH keys are missing on Config Drive disk in some cases
> [ConfigDrive] SSH keys are missing on Config Drive disk in some cases
> -
>
> Key: CLOUDSTACK-10358
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10358
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.11.0.0
>Reporter: Frank Maximus
>Assignee: Frank Maximus
>Priority: Major
> Fix For: 4.11.1.0
>
>
> Following use case fails:
> {quote}*Given* a network offering with UserData provided by ConfigDrive
> *And* a network using that offering
> *When* I deploy a VM, specifying a keypair
> *Then* the public-keys.txt file on the config drive disk attached to the vm
> contains the public key
> {quote}
> Actual behaviour:
> bq. public-keys.txt is missing
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10288) Config drive - Usedata corruption when gzipped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453994#comment-16453994 ] ASF subversion and git services commented on CLOUDSTACK-10288: -- Commit 85203248a4bf8a4c09742ba1c4ae236ee008a15f in cloudstack's branch refs/heads/4.11 from [~fmaximus] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=8520324 ] ConfigDrive fixes: CLOUDSTACK-10288, CLOUDSTACK-10289 (#2566) * CLOUDSTACK-10289: Config Drive Metadata: Use VM UUID instead of VM id * CLOUDSTACK-10288: Config Drive Userdata: support for binary userdata * CLOUDSTACK-10358: SSH keys are missing on Config Drive disk in some cases > Config drive - Usedata corruption when gzipped > --- > > Key: CLOUDSTACK-10288 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10288 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Rohit Yadav >Assignee: Frank Maximus >Priority: Major > Fix For: 4.11.1.0 > > > Should be able to create userdata via "echo hi | gzip | base64 -w0" and read > it back in VM via "mount -o loop /dev/sr1 /mnt/tmp; cat > /mnt/tmp/cloudstack/userdata/user_data.txt | gunzip" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10288) Config drive - Usedata corruption when gzipped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453999#comment-16453999 ] ASF subversion and git services commented on CLOUDSTACK-10288: -- Commit 85203248a4bf8a4c09742ba1c4ae236ee008a15f in cloudstack's branch refs/heads/4.11 from [~fmaximus] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=8520324 ] ConfigDrive fixes: CLOUDSTACK-10288, CLOUDSTACK-10289 (#2566) * CLOUDSTACK-10289: Config Drive Metadata: Use VM UUID instead of VM id * CLOUDSTACK-10288: Config Drive Userdata: support for binary userdata * CLOUDSTACK-10358: SSH keys are missing on Config Drive disk in some cases > Config drive - Usedata corruption when gzipped > --- > > Key: CLOUDSTACK-10288 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10288 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Rohit Yadav >Assignee: Frank Maximus >Priority: Major > Fix For: 4.11.1.0 > > > Should be able to create userdata via "echo hi | gzip | base64 -w0" and read > it back in VM via "mount -o loop /dev/sr1 /mnt/tmp; cat > /mnt/tmp/cloudstack/userdata/user_data.txt | gunzip" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10288) Config drive - Usedata corruption when gzipped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10288. - Resolution: Fixed Fix Version/s: 4.11.1.0 > Config drive - Usedata corruption when gzipped > --- > > Key: CLOUDSTACK-10288 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10288 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Rohit Yadav >Assignee: Frank Maximus >Priority: Major > Fix For: 4.11.1.0 > > > Should be able to create userdata via "echo hi | gzip | base64 -w0" and read > it back in VM via "mount -o loop /dev/sr1 /mnt/tmp; cat > /mnt/tmp/cloudstack/userdata/user_data.txt | gunzip" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10289) Config drive - Metadata leaking internal ids
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453997#comment-16453997
]
ASF subversion and git services commented on CLOUDSTACK-10289:
--
Commit 85203248a4bf8a4c09742ba1c4ae236ee008a15f in cloudstack's branch
refs/heads/4.11 from [~fmaximus]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=8520324 ]
ConfigDrive fixes: CLOUDSTACK-10288, CLOUDSTACK-10289 (#2566)
* CLOUDSTACK-10289: Config Drive Metadata: Use VM UUID instead of VM id
* CLOUDSTACK-10288: Config Drive Userdata: support for binary userdata
* CLOUDSTACK-10358: SSH keys are missing on Config Drive disk in some cases
> Config drive - Metadata leaking internal ids
>
>
> Key: CLOUDSTACK-10289
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10289
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.11.0.0
>Reporter: Rohit Yadav
>Assignee: Frank Maximus
>Priority: Major
>
> Metadata on config drive looks like this, which is different from what
> routervm userdata looks like. Leaking internal IDs:
> # for i in `ls`; do echo -n $i : ; cat $i; echo; done
> availability-zone.txt : zone1
> cloud-identifier.txt : CloudStack-\{af714831-9a23-4ee4-a415-984a6dae1c61}
> instance-id.txt : i-2-24-VM
> local-hostname.txt : i-2-24-VM
> service-offering.txt : Small Instance
> vm-id.txt : 24
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10289) Config drive - Metadata leaking internal ids
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453996#comment-16453996
]
ASF subversion and git services commented on CLOUDSTACK-10289:
--
Commit 85203248a4bf8a4c09742ba1c4ae236ee008a15f in cloudstack's branch
refs/heads/4.11 from [~fmaximus]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=8520324 ]
ConfigDrive fixes: CLOUDSTACK-10288, CLOUDSTACK-10289 (#2566)
* CLOUDSTACK-10289: Config Drive Metadata: Use VM UUID instead of VM id
* CLOUDSTACK-10288: Config Drive Userdata: support for binary userdata
* CLOUDSTACK-10358: SSH keys are missing on Config Drive disk in some cases
> Config drive - Metadata leaking internal ids
>
>
> Key: CLOUDSTACK-10289
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10289
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.11.0.0
>Reporter: Rohit Yadav
>Assignee: Frank Maximus
>Priority: Major
>
> Metadata on config drive looks like this, which is different from what
> routervm userdata looks like. Leaking internal IDs:
> # for i in `ls`; do echo -n $i : ; cat $i; echo; done
> availability-zone.txt : zone1
> cloud-identifier.txt : CloudStack-\{af714831-9a23-4ee4-a415-984a6dae1c61}
> instance-id.txt : i-2-24-VM
> local-hostname.txt : i-2-24-VM
> service-offering.txt : Small Instance
> vm-id.txt : 24
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10356) Fix Some Potential NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner resolved CLOUDSTACK-10356.
-
Resolution: Fixed
> Fix Some Potential NPE
> ---
>
> Key: CLOUDSTACK-10356
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10356
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.12.0.0
>Reporter: lujie
>Priority: Major
> Attachments: CLOUDSTACK-10356_1.patch
>
>
> We have developed a static analysis tool
> [NPEDetector|https://github.com/lujiefsi/NPEDetector] to find some potential
> NPE. Our analysis shows that some callees may return null in corner case(e.g.
> node crash , IO exception), some of their callers have _!=null_ check but
> some do not have. In this issue we post a patch which can add !=null based
> on existed !=null check. For example:
> Callee GlobalLoadBalancingRulesServiceImpl#lookupGslbServiceProvider:
> {code:java}
> protected GslbServiceProvider lookupGslbServiceProvider() {
> return _gslbProviders.size() == 0 ? null : _gslbProviders.get(0);// may
> return null;
> }
> {code}
> Caller GlobalLoadBalancingRulesServiceImpl#checkGslbServiceEnabledInZone have
> _!=null_:
> {code:java}
> private boolean checkGslbServiceEnabledInZone(long zoneId, long
> physicalNetworkId) {
>GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
>if (gslbProvider == null) {
> throw new CloudRuntimeException("No GSLB provider is available");
>}
>return gslbProvider.isServiceEnabledInZone(zoneId, physicalNetworkId);
> }
> {code}
> but another
> GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig does
> not have !=null check:
> {code:java}
> GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
> siteLb.setGslbProviderPublicIp(gslbProvider.getZoneGslbProviderPublicIp(dataCenterId,physicalNetworkId));
> .{code}
> So we will add below code in non-(!=null) caller
> GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig
> {code:java}
> if (gslbProvider == null) {
> throw new CloudRuntimeException("No GSLB provider is available");
> }
> {code}
> But due to we are not very familiar with CLOUDSTACK, hope some expert can
> review it.
> Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10356) Fix Some Potential NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner updated CLOUDSTACK-10356:
Fix Version/s: 4.12
> Fix Some Potential NPE
> ---
>
> Key: CLOUDSTACK-10356
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10356
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.12.0.0
>Reporter: lujie
>Priority: Major
> Fix For: 4.12
>
> Attachments: CLOUDSTACK-10356_1.patch
>
>
> We have developed a static analysis tool
> [NPEDetector|https://github.com/lujiefsi/NPEDetector] to find some potential
> NPE. Our analysis shows that some callees may return null in corner case(e.g.
> node crash , IO exception), some of their callers have _!=null_ check but
> some do not have. In this issue we post a patch which can add !=null based
> on existed !=null check. For example:
> Callee GlobalLoadBalancingRulesServiceImpl#lookupGslbServiceProvider:
> {code:java}
> protected GslbServiceProvider lookupGslbServiceProvider() {
> return _gslbProviders.size() == 0 ? null : _gslbProviders.get(0);// may
> return null;
> }
> {code}
> Caller GlobalLoadBalancingRulesServiceImpl#checkGslbServiceEnabledInZone have
> _!=null_:
> {code:java}
> private boolean checkGslbServiceEnabledInZone(long zoneId, long
> physicalNetworkId) {
>GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
>if (gslbProvider == null) {
> throw new CloudRuntimeException("No GSLB provider is available");
>}
>return gslbProvider.isServiceEnabledInZone(zoneId, physicalNetworkId);
> }
> {code}
> but another
> GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig does
> not have !=null check:
> {code:java}
> GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
> siteLb.setGslbProviderPublicIp(gslbProvider.getZoneGslbProviderPublicIp(dataCenterId,physicalNetworkId));
> .{code}
> So we will add below code in non-(!=null) caller
> GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig
> {code:java}
> if (gslbProvider == null) {
> throw new CloudRuntimeException("No GSLB provider is available");
> }
> {code}
> But due to we are not very familiar with CLOUDSTACK, hope some expert can
> review it.
> Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10356) Fix Some Potential NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453986#comment-16453986
]
ASF subversion and git services commented on CLOUDSTACK-10356:
--
Commit 4c42aafae0d3286a38d796a7c69a6aec6810cf79 in cloudstack's branch
refs/heads/master from brett
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=4c42aaf ]
[CLOUDSTACK-10356] Fix NPE in Cloudstack found with NPEDetector (#2573)
* fix https://issues.apache.org/jira/browse/CLOUDSTACK-10356
* del patch file
* Update ResourceCountDaoImpl.java
* fix some format
* fix code
* fix error message in VolumeOrchestrator
* add check null stmt
* del import unuse class
* use BooleanUtils to check Boolean
* fix error message
* delete unuse function
* delete the deprecated function updateDomainCount
* add error log and throw exception in ProjectManagerImpl.java
> Fix Some Potential NPE
> ---
>
> Key: CLOUDSTACK-10356
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10356
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.12.0.0
>Reporter: lujie
>Priority: Major
> Attachments: CLOUDSTACK-10356_1.patch
>
>
> We have developed a static analysis tool
> [NPEDetector|https://github.com/lujiefsi/NPEDetector] to find some potential
> NPE. Our analysis shows that some callees may return null in corner case(e.g.
> node crash , IO exception), some of their callers have _!=null_ check but
> some do not have. In this issue we post a patch which can add !=null based
> on existed !=null check. For example:
> Callee GlobalLoadBalancingRulesServiceImpl#lookupGslbServiceProvider:
> {code:java}
> protected GslbServiceProvider lookupGslbServiceProvider() {
> return _gslbProviders.size() == 0 ? null : _gslbProviders.get(0);// may
> return null;
> }
> {code}
> Caller GlobalLoadBalancingRulesServiceImpl#checkGslbServiceEnabledInZone have
> _!=null_:
> {code:java}
> private boolean checkGslbServiceEnabledInZone(long zoneId, long
> physicalNetworkId) {
>GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
>if (gslbProvider == null) {
> throw new CloudRuntimeException("No GSLB provider is available");
>}
>return gslbProvider.isServiceEnabledInZone(zoneId, physicalNetworkId);
> }
> {code}
> but another
> GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig does
> not have !=null check:
> {code:java}
> GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
> siteLb.setGslbProviderPublicIp(gslbProvider.getZoneGslbProviderPublicIp(dataCenterId,physicalNetworkId));
> .{code}
> So we will add below code in non-(!=null) caller
> GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig
> {code:java}
> if (gslbProvider == null) {
> throw new CloudRuntimeException("No GSLB provider is available");
> }
> {code}
> But due to we are not very familiar with CLOUDSTACK, hope some expert can
> review it.
> Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10356) Fix Some Potential NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453983#comment-16453983
]
ASF GitHub Bot commented on CLOUDSTACK-10356:
-
rafaelweingartner closed pull request #2573: [CLOUDSTACK-10356] Fix NPE in
Cloudstack found with NPEDetector
URL: https://github.com/apache/cloudstack/pull/2573
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/engine/orchestration/src/main/java/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
b/engine/orchestration/src/main/java/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
index f02fdc495f9..c8279ff3f99 100644
---
a/engine/orchestration/src/main/java/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
+++
b/engine/orchestration/src/main/java/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
@@ -499,6 +499,9 @@ public VolumeInfo copyVolumeFromSecToPrimary(VolumeInfo
volume, VirtualMachine v
// Find a suitable storage to create volume on
StoragePool destPool = findStoragePool(dskCh, dc, pod, clusterId,
null, vm, avoidPools);
+if (destPool == null) {
+throw new CloudRuntimeException("Failed to find a suitable storage
pool to create Volume in the pod/cluster of the provided VM "+ vm.getUuid());
+}
DataStore destStore = dataStoreMgr.getDataStore(destPool.getId(),
DataStoreRole.Primary);
AsyncCallFuture future =
volService.copyVolume(volume, destStore);
diff --git
a/engine/schema/src/main/java/com/cloud/configuration/dao/ResourceCountDao.java
b/engine/schema/src/main/java/com/cloud/configuration/dao/ResourceCountDao.java
index b5a75d196fa..28f2a536071 100644
---
a/engine/schema/src/main/java/com/cloud/configuration/dao/ResourceCountDao.java
+++
b/engine/schema/src/main/java/com/cloud/configuration/dao/ResourceCountDao.java
@@ -39,9 +39,6 @@
*/
void setResourceCount(long ownerId, ResourceOwnerType ownerType,
ResourceType type, long count);
-@Deprecated
-void updateDomainCount(long domainId, ResourceType type, boolean
increment, long delta);
-
boolean updateById(long id, boolean increment, long delta);
void createResourceCounts(long ownerId, ResourceOwnerType ownerType);
diff --git
a/engine/schema/src/main/java/com/cloud/configuration/dao/ResourceCountDaoImpl.java
b/engine/schema/src/main/java/com/cloud/configuration/dao/ResourceCountDaoImpl.java
index 56261337faf..dbf2228183b 100644
---
a/engine/schema/src/main/java/com/cloud/configuration/dao/ResourceCountDaoImpl.java
+++
b/engine/schema/src/main/java/com/cloud/configuration/dao/ResourceCountDaoImpl.java
@@ -120,16 +120,6 @@ public void setResourceCount(long ownerId,
ResourceOwnerType ownerType, Resource
}
}
-@Override
-@Deprecated
-public void updateDomainCount(long domainId, ResourceType type, boolean
increment, long delta) {
-delta = increment ? delta : delta * -1;
-
-ResourceCountVO resourceCountVO = findByOwnerAndType(domainId,
ResourceOwnerType.Domain, type);
-resourceCountVO.setCount(resourceCountVO.getCount() + delta);
-update(resourceCountVO.getId(), resourceCountVO);
-}
-
@Override
public boolean updateById(long id, boolean increment, long delta) {
delta = increment ? delta : delta * -1;
diff --git
a/plugins/deployment-planners/implicit-dedication/src/main/java/com/cloud/deploy/ImplicitDedicationPlanner.java
b/plugins/deployment-planners/implicit-dedication/src/main/java/com/cloud/deploy/ImplicitDedicationPlanner.java
index 5bad9226eed..45f16abd2af 100644
---
a/plugins/deployment-planners/implicit-dedication/src/main/java/com/cloud/deploy/ImplicitDedicationPlanner.java
+++
b/plugins/deployment-planners/implicit-dedication/src/main/java/com/cloud/deploy/ImplicitDedicationPlanner.java
@@ -39,6 +39,7 @@
import com.cloud.utils.NumbersUtil;
import com.cloud.vm.VMInstanceVO;
import com.cloud.vm.VirtualMachineProfile;
+import org.springframework.util.CollectionUtils;
public class ImplicitDedicationPlanner extends FirstFitPlanner implements
DeploymentClusterPlanner {
@@ -256,14 +257,15 @@ public PlannerResourceUsage
getResourceUsage(VirtualMachineProfile vmProfile, De
// Get the list of all the hosts in the given clusters
List allHosts = new ArrayList();
-for (Long cluster : clusterList) {
-List hostsInCluster =
resourceMgr.listAllHostsInCluster(cluster);
-for (HostVO hostVO : hostsInCluster) {
+if (!CollectionUtils.isEmpty(clusterList)) {
+for (Long cluster : clus
[jira] [Commented] (CLOUDSTACK-10356) Fix Some Potential NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453985#comment-16453985
]
ASF subversion and git services commented on CLOUDSTACK-10356:
--
Commit 4c42aafae0d3286a38d796a7c69a6aec6810cf79 in cloudstack's branch
refs/heads/master from brett
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=4c42aaf ]
[CLOUDSTACK-10356] Fix NPE in Cloudstack found with NPEDetector (#2573)
* fix https://issues.apache.org/jira/browse/CLOUDSTACK-10356
* del patch file
* Update ResourceCountDaoImpl.java
* fix some format
* fix code
* fix error message in VolumeOrchestrator
* add check null stmt
* del import unuse class
* use BooleanUtils to check Boolean
* fix error message
* delete unuse function
* delete the deprecated function updateDomainCount
* add error log and throw exception in ProjectManagerImpl.java
> Fix Some Potential NPE
> ---
>
> Key: CLOUDSTACK-10356
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10356
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.12.0.0
>Reporter: lujie
>Priority: Major
> Attachments: CLOUDSTACK-10356_1.patch
>
>
> We have developed a static analysis tool
> [NPEDetector|https://github.com/lujiefsi/NPEDetector] to find some potential
> NPE. Our analysis shows that some callees may return null in corner case(e.g.
> node crash , IO exception), some of their callers have _!=null_ check but
> some do not have. In this issue we post a patch which can add !=null based
> on existed !=null check. For example:
> Callee GlobalLoadBalancingRulesServiceImpl#lookupGslbServiceProvider:
> {code:java}
> protected GslbServiceProvider lookupGslbServiceProvider() {
> return _gslbProviders.size() == 0 ? null : _gslbProviders.get(0);// may
> return null;
> }
> {code}
> Caller GlobalLoadBalancingRulesServiceImpl#checkGslbServiceEnabledInZone have
> _!=null_:
> {code:java}
> private boolean checkGslbServiceEnabledInZone(long zoneId, long
> physicalNetworkId) {
>GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
>if (gslbProvider == null) {
> throw new CloudRuntimeException("No GSLB provider is available");
>}
>return gslbProvider.isServiceEnabledInZone(zoneId, physicalNetworkId);
> }
> {code}
> but another
> GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig does
> not have !=null check:
> {code:java}
> GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
> siteLb.setGslbProviderPublicIp(gslbProvider.getZoneGslbProviderPublicIp(dataCenterId,physicalNetworkId));
> .{code}
> So we will add below code in non-(!=null) caller
> GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig
> {code:java}
> if (gslbProvider == null) {
> throw new CloudRuntimeException("No GSLB provider is available");
> }
> {code}
> But due to we are not very familiar with CLOUDSTACK, hope some expert can
> review it.
> Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10374) Remove branches "hotfix*"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner updated CLOUDSTACK-10374:
Summary: Remove branches "hotfix*" (was: Remove branches “hotfix*")
> Remove branches "hotfix*"
> -
>
> Key: CLOUDSTACK-10374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10374
> Project: CloudStack
> Issue Type: Sub-task
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> Following the protocol defined in [1]. We will remove branches "Remove
> branches matching the expressions.
> {code:java}
> hotfix*
> {code}
> The branches that will be removed are the following:
> * hotfix/3383
> * hotfix/4.4-1632
> * hotfix/4.4-401
> * hotfix/4.4-7006
> * hotfix/4.4-7193
> * hotfix/4.4-7343
> * hotfix/4.4-7405
> * hotfix/4.4-7418
> * hotfix/4.4-7468
> * hotfix/4.4-7574
> * hotfix/4.4-7822
> * hotfix/4.4-7952
> * hotfix/4.4-generateapi
> * hotfix/4.4-sysctl-improvements
> * hotfix/4.4/CLOUDSTACK-7184
> * hotfix/4.4/CLOUDSTACK-7219
> * hotfix/4.4/CLOUDSTACK-7528
> * hotfix/4.4/CLOUDSTACK-7624
> * hotfix/4.4/CLOUDSTACK-8073
> * hotfix/4.5-7822
> * hotfix/4.5-7952
> * hotfix/4.5-7959
> * hotfix/CID-1256277
> * hotfix/CLOUDSTACK-6212
> * hotfix/CLOUDSTACK-7776
> * hotfix/CLOUDSTACK-7887
> * hotfix/findbugs-unknownvm-as-null
>
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10374) Remove branches “hotfix*"
Rafael Weingärtner created CLOUDSTACK-10374:
---
Summary: Remove branches “hotfix*"
Key: CLOUDSTACK-10374
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10374
Project: CloudStack
Issue Type: Sub-task
Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Rafael Weingärtner
Assignee: Rafael Weingärtner
Following the protocol defined in [1]. We will remove branches "Remove branches
matching the expressions.
{code:java}
hotfix*
{code}
The branches that will be removed are the following:
* hotfix/3383
* hotfix/4.4-1632
* hotfix/4.4-401
* hotfix/4.4-7006
* hotfix/4.4-7193
* hotfix/4.4-7343
* hotfix/4.4-7405
* hotfix/4.4-7418
* hotfix/4.4-7468
* hotfix/4.4-7574
* hotfix/4.4-7822
* hotfix/4.4-7952
* hotfix/4.4-generateapi
* hotfix/4.4-sysctl-improvements
* hotfix/4.4/CLOUDSTACK-7184
* hotfix/4.4/CLOUDSTACK-7219
* hotfix/4.4/CLOUDSTACK-7528
* hotfix/4.4/CLOUDSTACK-7624
* hotfix/4.4/CLOUDSTACK-8073
* hotfix/4.5-7822
* hotfix/4.5-7952
* hotfix/4.5-7959
* hotfix/CID-1256277
* hotfix/CLOUDSTACK-6212
* hotfix/CLOUDSTACK-7776
* hotfix/CLOUDSTACK-7887
* hotfix/findbugs-unknownvm-as-null
[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-8959) Option to remove mapping of the config drive when deploying VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453800#comment-16453800 ] ASF GitHub Bot commented on CLOUDSTACK-8959: DaanHoogland commented on issue #2116: CLOUDSTACK-8959: Option to attach the config drive URL: https://github.com/apache/cloudstack/pull/2116#issuecomment-384590959 @fmaximus did you already incorporate the changes here, maybe except the setting part? In case you did we can close this one. 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 > Option to remove mapping of the config drive when deploying VM > -- > > Key: CLOUDSTACK-8959 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8959 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kshitij Kansal >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-8609) [VMware] VM is not accessible after a migration across clusters.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453740#comment-16453740 ] ASF GitHub Bot commented on CLOUDSTACK-8609: resmo commented on issue #2091: CLOUDSTACK-8609: [VMware] VM is not accessible after migration across clusters URL: https://github.com/apache/cloudstack/pull/2091#issuecomment-384573516 I would like to see this in 4.11.1 @rhtyd 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 > [VMware] VM is not accessible after a migration across clusters. > > > Key: CLOUDSTACK-8609 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8609 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Likitha Shetty >Assignee: Suresh Kumar Anaparti >Priority: Major > Fix For: Future > > > +Steps to reproduce+ > 1. Deploy a VMware zone with 2 clusters (a host each, H1 and H2) and one > zone-wide primary storage spanning the two clusters. > 2. Deploy a VM (VM1) on one of the hosts (H1). > 3. Stop VM1. > 4. Make the host that contains the VM unsuitable for further VM deployments > - host runs out of capacity (cpu/memory) > - host has maximum VMs deployed on it > 5. Start VM1. > 6. VM will be powered on H2 but will not be accessible because the .vmx and > other VM files associated with the VM have been deleted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
