[jira] [Commented] (CLOUDSTACK-10329) Button in ACL rules page to export all rules as a CSV file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16402420#comment-16402420 ] ASF GitHub Bot commented on CLOUDSTACK-10329: - rafaelweingartner opened a new pull request #2494: [CLOUDSTACK-10329] Button in ACL rules page to export all rules as a CSV file URL: https://github.com/apache/cloudstack/pull/2494 This PR introduces a new button in ACS UI to export ACL rules in a CSV file. This is useful for reporting ACL rules configured. The following picture is a screenshot.  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 > Button in ACL rules page to export all rules as a CSV file > --- > > Key: CLOUDSTACK-10329 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10329 > Project: CloudStack > Issue Type: New Feature > 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 > > > It is interesting to create a button in the ACL rule listing page to export > all rules in a CSV file. This file can facilitate the auditing and reporting > of rules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10329) Button in ACL rules page to export all rules as a CSV file
Rafael Weingärtner created CLOUDSTACK-10329: --- Summary: Button in ACL rules page to export all rules as a CSV file Key: CLOUDSTACK-10329 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10329 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rafael Weingärtner Assignee: Rafael Weingärtner Fix For: 4.12 It is interesting to create a button in the ACL rule listing page to export all rules in a CSV file. This file can facilitate the auditing and reporting of rules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16402269#comment-16402269 ] ASF GitHub Bot commented on CLOUDSTACK-10326: - blueorangutan commented on issue #2493: CLOUDSTACK-10326: Prevent hosts fall into Maintenance when there are running VMs on it URL: https://github.com/apache/cloudstack/pull/2493#issuecomment-373795841 Trillian test result (tid-2385) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 27077 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2493-t2385-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_deploy_virtio_scsi_vm.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 65 look OK, 2 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_rvpc_network_garbage_collector_nics | `Failure` | 479.67 | test_vpc_redundant.py test_hostha_enable_ha_when_host_in_maintenance | `Error` | 1.69 | test_hostha_kvm.py This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Prevent hosts fall into Maintenance when there are running VMs on it > > > Key: CLOUDSTACK-10326 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.0 > > Attachments: CLOUDSTACK-10326-Debug.png, > CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png, > CLOUDSTACK-10326-MigrationFailed.png > > > This issue was discovered, fixed and tested on KVM, but applies for every > hypervisor. > h2. Background > When enabling maintenance mode in a host, host state is put into > 'PrepareForMaintenance' and running VMs are migrated into another host. After > every VM is migrated, host goes to 'Maintenance' state. > Checks are performed on ResourceManagerImpl.checkAndMaintan() method: > * List VMs with host_id = HOST_ID > * List VMs with last_host_id = HOST_ID and state=Migrating > When both queries are empty, then the host can be put into Maintenance. > When a VM is being migrated to DEST_HOST, its host_id column is set to > DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then > migration fails, host_id = last_host_id = ORIGIN_HOST > h2. Issue > This sequence: > * Enable maintenance mode on ORIGIN_HOST > * VMs start being migrated to a host, say DEST_HOST > * checkAndMaintain() starts: > ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are > being migrated) > ** Before the second check, one or more migrations fail > ** Second check passes, however there are VMs running on the host as > migrations have failed. > * Host goes into Maintenance state. > Screenshots attached, query executed on each case: > select id, name, instance_name, state, host_id, last_host_id from vm_instance; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10301) Allow updating the network ACL list name and Description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16402082#comment-16402082 ] ASF GitHub Bot commented on CLOUDSTACK-10301: - blueorangutan commented on issue #2462: [CLOUDSTACK-10301] Allow updating the network ACL list name and Description URL: https://github.com/apache/cloudstack/pull/2462#issuecomment-373756880 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1788 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 updating the network ACL list name and Description > - > > Key: CLOUDSTACK-10301 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10301 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Currently, it is not possible to update the Network ACL name or Description > of an ACL after it has been created. It might be interesting to expose this > option via API and to add this feature to the UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10320) Invalid pair for response object breaking response parsing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16402078#comment-16402078
]
ASF GitHub Bot commented on CLOUDSTACK-10320:
-
blueorangutan commented on issue #2481: CLOUDSTACK-10320 - Invalid pair for
response object breaking response parsing
URL: https://github.com/apache/cloudstack/pull/2481#issuecomment-373756211
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1787
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
> Invalid pair for response object breaking response parsing
> --
>
> Key: CLOUDSTACK-10320
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10320
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>Priority: Major
>
> Under some circumstances, the API is returning an invalid response, for
> simplicity I will expose the JSON case. The API response on a
> listVirtualMachines can be this string:
> {code:java}
> { "listvirtualmachinesresponse" : ] } }{code}
> To understand how this is possible, assume you have more than one management
> server and one is processing the destroy of a virtual machine in the account
> X which is the only one it has. Another process is returning the result of
> listVirtualMachines for that same account X. During the listVM command, the
> result set is fetch with a searchAndDistinctCount due to the view
> ([https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/query/QueryManagerImpl.java#L1024).]
> This is done through 2 queries in the GenericDao
> [https://github.com/apache/cloudstack/blob/master/framework/db/src/main/java/com/cloud/utils/db/GenericDaoBase.java#L1323]
> and if you encounter the _right_ conditions, the VM will be marked as
> removed in between those 2 queries. This results in having a Pair result with
> at least one object but a count of 0. Then following how is done the
> serialization of the response at
> [https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/response/ApiResponseSerializer.java#L86]
> you will reach the case where your output is the one previously mentioned.
> To overcome this issue, there isn't a true fix but only a better pair
> response to ensure a correct response formatting. If the result set contains
> at least something, the count cannot be 0 but we cannot guess the correct
> answer, but only state it has at least one element.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10307) Remove unused things from HostDaoImpl
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16402047#comment-16402047 ] ASF GitHub Bot commented on CLOUDSTACK-10307: - GabrielBrascher commented on issue #2438: [CLOUDSTACK-10307] Remove unused things from HostDaoImpl URL: https://github.com/apache/cloudstack/pull/2438#issuecomment-373748297 Thanks, @rafaelweingartner! Based on code review and that you have checked all the ways that a code has to be called, this PR LGTM. 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 > Remove unused things from HostDaoImpl > - > > Key: CLOUDSTACK-10307 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10307 > 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: Minor > > Remove unnecessary annotation of HostDaoImpl. While removing this annotation > I noticed that one of the methods were not necessary. While removing it, I > found some code in CloudZonesStartupProcessor that was also not used, and > removed it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10301) Allow updating the network ACL list name and Description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16402015#comment-16402015 ] ASF GitHub Bot commented on CLOUDSTACK-10301: - blueorangutan commented on issue #2462: [CLOUDSTACK-10301] Allow updating the network ACL list name and Description URL: https://github.com/apache/cloudstack/pull/2462#issuecomment-373741187 @rafaelweingartner a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Allow updating the network ACL list name and Description > - > > Key: CLOUDSTACK-10301 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10301 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Currently, it is not possible to update the Network ACL name or Description > of an ACL after it has been created. It might be interesting to expose this > option via API and to add this feature to the UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10320) Invalid pair for response object breaking response parsing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16402011#comment-16402011
]
ASF GitHub Bot commented on CLOUDSTACK-10320:
-
blueorangutan commented on issue #2481: CLOUDSTACK-10320 - Invalid pair for
response object breaking response parsing
URL: https://github.com/apache/cloudstack/pull/2481#issuecomment-373740886
@rafaelweingartner a Jenkins job has been kicked to build packages. I'll
keep you posted as I make progress.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Invalid pair for response object breaking response parsing
> --
>
> Key: CLOUDSTACK-10320
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10320
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>Priority: Major
>
> Under some circumstances, the API is returning an invalid response, for
> simplicity I will expose the JSON case. The API response on a
> listVirtualMachines can be this string:
> {code:java}
> { "listvirtualmachinesresponse" : ] } }{code}
> To understand how this is possible, assume you have more than one management
> server and one is processing the destroy of a virtual machine in the account
> X which is the only one it has. Another process is returning the result of
> listVirtualMachines for that same account X. During the listVM command, the
> result set is fetch with a searchAndDistinctCount due to the view
> ([https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/query/QueryManagerImpl.java#L1024).]
> This is done through 2 queries in the GenericDao
> [https://github.com/apache/cloudstack/blob/master/framework/db/src/main/java/com/cloud/utils/db/GenericDaoBase.java#L1323]
> and if you encounter the _right_ conditions, the VM will be marked as
> removed in between those 2 queries. This results in having a Pair result with
> at least one object but a count of 0. Then following how is done the
> serialization of the response at
> [https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/response/ApiResponseSerializer.java#L86]
> you will reach the case where your output is the one previously mentioned.
> To overcome this issue, there isn't a true fix but only a better pair
> response to ensure a correct response formatting. If the result set contains
> at least something, the count cannot be 0 but we cannot guess the correct
> answer, but only state it has at least one element.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10301) Allow updating the network ACL list name and Description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16402009#comment-16402009 ] ASF GitHub Bot commented on CLOUDSTACK-10301: - rafaelweingartner commented on issue #2462: [CLOUDSTACK-10301] Allow updating the network ACL list name and Description URL: https://github.com/apache/cloudstack/pull/2462#issuecomment-373740870 @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 > Allow updating the network ACL list name and Description > - > > Key: CLOUDSTACK-10301 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10301 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Currently, it is not possible to update the Network ACL name or Description > of an ACL after it has been created. It might be interesting to expose this > option via API and to add this feature to the UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10320) Invalid pair for response object breaking response parsing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16402008#comment-16402008
]
ASF GitHub Bot commented on CLOUDSTACK-10320:
-
rafaelweingartner commented on issue #2481: CLOUDSTACK-10320 - Invalid pair for
response object breaking response parsing
URL: https://github.com/apache/cloudstack/pull/2481#issuecomment-373740594
@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
> Invalid pair for response object breaking response parsing
> --
>
> Key: CLOUDSTACK-10320
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10320
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>Priority: Major
>
> Under some circumstances, the API is returning an invalid response, for
> simplicity I will expose the JSON case. The API response on a
> listVirtualMachines can be this string:
> {code:java}
> { "listvirtualmachinesresponse" : ] } }{code}
> To understand how this is possible, assume you have more than one management
> server and one is processing the destroy of a virtual machine in the account
> X which is the only one it has. Another process is returning the result of
> listVirtualMachines for that same account X. During the listVM command, the
> result set is fetch with a searchAndDistinctCount due to the view
> ([https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/query/QueryManagerImpl.java#L1024).]
> This is done through 2 queries in the GenericDao
> [https://github.com/apache/cloudstack/blob/master/framework/db/src/main/java/com/cloud/utils/db/GenericDaoBase.java#L1323]
> and if you encounter the _right_ conditions, the VM will be marked as
> removed in between those 2 queries. This results in having a Pair result with
> at least one object but a count of 0. Then following how is done the
> serialization of the response at
> [https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/response/ApiResponseSerializer.java#L86]
> you will reach the case where your output is the one previously mentioned.
> To overcome this issue, there isn't a true fix but only a better pair
> response to ensure a correct response formatting. If the result set contains
> at least something, the count cannot be 0 but we cannot guess the correct
> answer, but only state it has at least one element.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16402004#comment-16402004
]
ASF GitHub Bot commented on CLOUDSTACK-10326:
-
rafaelweingartner commented on a change in pull request #2493:
CLOUDSTACK-10326: Prevent hosts fall into Maintenance when there are running
VMs on it
URL: https://github.com/apache/cloudstack/pull/2493#discussion_r175036445
##
File path: server/src/com/cloud/resource/ResourceManagerImpl.java
##
@@ -1296,7 +1296,8 @@ public boolean checkAndMaintain(final long hostId) {
if (host.getType() != Host.Type.Storage) {
final List vos = _vmDao.listByHostId(hostId);
final List vosMigrating =
_vmDao.listVmsMigratingFromHost(hostId);
-if (vos.isEmpty() && vosMigrating.isEmpty()) {
+final List failedMigratedVms =
_vmDao.listRunningVmsByHostAndLastHostSameId(hostId);
+if (vos.isEmpty() && vosMigrating.isEmpty() &&
failedMigratedVms.isEmpty()) {
Review comment:
And also unit testing
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
> Prevent hosts fall into Maintenance when there are running VMs on it
>
>
> Key: CLOUDSTACK-10326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
> Fix For: 4.11.1.0
>
> Attachments: CLOUDSTACK-10326-Debug.png,
> CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png,
> CLOUDSTACK-10326-MigrationFailed.png
>
>
> This issue was discovered, fixed and tested on KVM, but applies for every
> hypervisor.
> h2. Background
> When enabling maintenance mode in a host, host state is put into
> 'PrepareForMaintenance' and running VMs are migrated into another host. After
> every VM is migrated, host goes to 'Maintenance' state.
> Checks are performed on ResourceManagerImpl.checkAndMaintan() method:
> * List VMs with host_id = HOST_ID
> * List VMs with last_host_id = HOST_ID and state=Migrating
> When both queries are empty, then the host can be put into Maintenance.
> When a VM is being migrated to DEST_HOST, its host_id column is set to
> DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then
> migration fails, host_id = last_host_id = ORIGIN_HOST
> h2. Issue
> This sequence:
> * Enable maintenance mode on ORIGIN_HOST
> * VMs start being migrated to a host, say DEST_HOST
> * checkAndMaintain() starts:
> ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are
> being migrated)
> ** Before the second check, one or more migrations fail
> ** Second check passes, however there are VMs running on the host as
> migrations have failed.
> * Host goes into Maintenance state.
> Screenshots attached, query executed on each case:
> select id, name, instance_name, state, host_id, last_host_id from vm_instance;
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10328) Add Secondary IPv6 address through API
Gabriel Beims Bräscher created CLOUDSTACK-10328: --- Summary: Add Secondary IPv6 address through API Key: CLOUDSTACK-10328 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10328 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 Currently, we have IPv6 support in Basic Networking. However, CloudStack does not support Multiple IPv6 addresses. This was partially implemented with this Pull Request: https://github.com/apache/cloudstack/pull/2028 The addIpToNic command only supports IPv4: https://cloudstack.apache.org/api/apidocs-4.11/apis/addIpToNic.html Features: - Add IPv6 address alias - Check if this IPv6 address is in the configured subnet for that POD/VLAN - Update the security group The admin will manually add the address to the Instance but the Security Grouping should allow it. -- 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=16401749#comment-16401749 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - DaanHoogland commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373681628 thanks @rafaelweingartner , didn't notice the relation This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10327) SSO fails with error "Session Expired", except for root admin
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lemasle updated CLOUDSTACK-10327:
-
Description:
CloudStack SSO (using {{security.singlesignon.key}}) does not work anymore with
CloudStack 4.11, since commit
[9988c26|https://github.com/apache/cloudstack/commit/9988c269b259b84c0b8436bad17f88dbc1d706e7#diff-16f2bfa56c6e8760760dd2b27b47d5b4]
This commit introduced a new feature (the ability to limit admin API calls to a
network CIDR), but also a regression due to a refactoring: every API request
that is not "validated" generates the same error (401 - Unauthorized) and
*invalidates the session*.
However, during an SSO login, CloudStack executes (since CS 4.7), a [call to
"listConfigurations"|https://github.com/apache/cloudstack/blob/8a3943b7632eddf3856a19e7d9a3fee82dd325be/ui/scripts/cloudStack.js#L172],
an API command reserved for root admins. When the user is not a root admin, he
does not have the privileges for this command.
With CloudStack up to 4.10, an error 432 was returned (and ignored):
{noformat}
{"errorresponse":\{"uuidList":[],"errorcode":432,"cserrorcode":,"errortext":"The
user is not allowed to request the API command or the API command does not
exist"}}
{noformat}
With CloudStack 4.11, the error 432 is replaced by an error 401 and the session
is invalidated. Then the next API calls lead to an error "Session Expired" and
the user cannot log in.
{noformat}
{"listconfigurationsresponse":\{"uuidList":[],"errorcode":401,"errortext":"unable
to verify user credentials and/or request signature"}}
{noformat}
was:
CloudStack SSO (using {{security.singlesignon.key}}) does not work anymore with
CloudStack 4.11, since commit
[9988c26|https://github.com/apache/cloudstack/commit/9988c269b259b84c0b8436bad17f88dbc1d706e7#diff-16f2bfa56c6e8760760dd2b27b47d5b4]
This commit introduced a new feature (the ability to limit admin API calls to a
network CIDR), but also a regression due to a refactoring: every API request
that is not "validated" generates the same error (401 - Unauthorized) and
*invalidates the session*.
However, during an SSO login, CloudStack executes (since CS 4.7), a [call to
"listConfigurations"|https://github.com/apache/cloudstack/blob/8a3943b7632eddf3856a19e7d9a3fee82dd325be/ui/scripts/cloudStack.js#L172],
an API command reserved for root admins. When the user is not a root admin, he
does not have the privileges for this command.
With CloudStack up to 4.10, an error 432 was returned (and ignored):
{{{"errorresponse":\{"uuidList":[],"errorcode":432,"cserrorcode":,"errortext":"The
user is not allowed to request the API command or the API command does not
exist"
With CloudStack 4.11, the error 432 is replaced by an error 401 and the session
is invalidated. Then the next API calls lead to an error "Session Expired" and
the user cannot log in.
{{{"listconfigurationsresponse":\{"uuidList":[],"errorcode":401,"errortext":"unable
to verify user credentials and/or request signature"
> SSO fails with error "Session Expired", except for root admin
> -
>
> Key: CLOUDSTACK-10327
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10327
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.11.0.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Critical
>
> CloudStack SSO (using {{security.singlesignon.key}}) does not work anymore
> with CloudStack 4.11, since commit
> [9988c26|https://github.com/apache/cloudstack/commit/9988c269b259b84c0b8436bad17f88dbc1d706e7#diff-16f2bfa56c6e8760760dd2b27b47d5b4]
> This commit introduced a new feature (the ability to limit admin API calls to
> a network CIDR), but also a regression due to a refactoring: every API
> request that is not "validated" generates the same error (401 - Unauthorized)
> and *invalidates the session*.
> However, during an SSO login, CloudStack executes (since CS 4.7), a [call to
> "listConfigurations"|https://github.com/apache/cloudstack/blob/8a3943b7632eddf3856a19e7d9a3fee82dd325be/ui/scripts/cloudStack.js#L172],
> an API command reserved for root admins. When the user is not a root admin,
> he does not have the privileges for this command.
> With CloudStack up to 4.10, an error 432 was returned (and ignored):
> {noformat}
> {"errorresponse":\{"uuidList":[],"errorcode":432,"cserrorcode":,"errortext":"The
> user is not allowed to request the API command or the API command does not
> exist"}}
> {noformat}
> With CloudStack 4.11, the error 432 is replaced by an error 401 and the
> session is invalidated. Then the next API calls lead to an error "Session
> Ex
[jira] [Created] (CLOUDSTACK-10327) SSO fails with error "Session Expired", except for root admin
Olivier Lemasle created CLOUDSTACK-10327:
Summary: SSO fails with error "Session Expired", except for root
admin
Key: CLOUDSTACK-10327
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10327
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: API
Affects Versions: 4.11.0.0
Reporter: Olivier Lemasle
Assignee: Olivier Lemasle
CloudStack SSO (using {{security.singlesignon.key}}) does not work anymore with
CloudStack 4.11, since commit
[9988c26|https://github.com/apache/cloudstack/commit/9988c269b259b84c0b8436bad17f88dbc1d706e7#diff-16f2bfa56c6e8760760dd2b27b47d5b4]
This commit introduced a new feature (the ability to limit admin API calls to a
network CIDR), but also a regression due to a refactoring: every API request
that is not "validated" generates the same error (401 - Unauthorized) and
*invalidates the session*.
However, during an SSO login, CloudStack executes (since CS 4.7), a [call to
"listConfigurations"|https://github.com/apache/cloudstack/blob/8a3943b7632eddf3856a19e7d9a3fee82dd325be/ui/scripts/cloudStack.js#L172],
an API command reserved for root admins. When the user is not a root admin, he
does not have the privileges for this command.
With CloudStack up to 4.10, an error 432 was returned (and ignored):
{{{"errorresponse":\{"uuidList":[],"errorcode":432,"cserrorcode":,"errortext":"The
user is not allowed to request the API command or the API command does not
exist"
With CloudStack 4.11, the error 432 is replaced by an error 401 and the session
is invalidated. Then the next API calls lead to an error "Session Expired" and
the user cannot log in.
{{{"listconfigurationsresponse":\{"uuidList":[],"errorcode":401,"errortext":"unable
to verify user credentials and/or request signature"
--
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=16401726#comment-16401726 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373676101 @DaanHoogland now everything is ok again. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-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=16401706#comment-16401706 ] 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-37303 Sorry by the delay @rafaelweingartner, I will do it soon. 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 > 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-10278) Adding a SQL table column is not Idempotent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401674#comment-16401674 ] ASF GitHub Bot commented on CLOUDSTACK-10278: - rafaelweingartner commented on issue #2449: WIP CLOUDSTACK-10278 idempotent column addition URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-373656370 I think we can go forward with this PR. I notice a Flyway DB PR, but that is not all. We need a protocol to create/maintain scripts (especially scripts created in minor versions). Also, in my opinion, if we are going with flyway, we need to lock down on a version, and remove all legacy thing. 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 > Adding a SQL table column is not Idempotent > --- > > Key: CLOUDSTACK-10278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.10.0.0, 4.11.0.0 >Reporter: Ernie Janse van Rensburg >Assignee: Ernie Janse van Rensburg >Priority: Major > Original Estimate: 4h > Remaining Estimate: 4h > > The SQL code to add a new column to a table in the > META-INF/db/schema-41000to41100.sql script is not written in an idempotent > way. When the upgrade is re-run, the code above causes a SQL error as > reported on the user mailing list: > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) > Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc > INT(1) NOT NULL DEFAULT 0 > This is a more generic problem for every version due to to the fact that it > is not idempotent > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401672#comment-16401672
]
ASF GitHub Bot commented on CLOUDSTACK-10326:
-
rafaelweingartner commented on a change in pull request #2493:
CLOUDSTACK-10326: Prevent hosts fall into Maintenance when there are running
VMs on it
URL: https://github.com/apache/cloudstack/pull/2493#discussion_r175036445
##
File path: server/src/com/cloud/resource/ResourceManagerImpl.java
##
@@ -1296,7 +1296,8 @@ public boolean checkAndMaintain(final long hostId) {
if (host.getType() != Host.Type.Storage) {
final List vos = _vmDao.listByHostId(hostId);
final List vosMigrating =
_vmDao.listVmsMigratingFromHost(hostId);
-if (vos.isEmpty() && vosMigrating.isEmpty()) {
+final List failedMigratedVms =
_vmDao.listRunningVmsByHostAndLastHostSameId(hostId);
+if (vos.isEmpty() && vosMigrating.isEmpty() &&
failedMigratedVms.isEmpty()) {
Review comment:
This also unit testing
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
> Prevent hosts fall into Maintenance when there are running VMs on it
>
>
> Key: CLOUDSTACK-10326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
> Fix For: 4.11.1.0
>
> Attachments: CLOUDSTACK-10326-Debug.png,
> CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png,
> CLOUDSTACK-10326-MigrationFailed.png
>
>
> This issue was discovered, fixed and tested on KVM, but applies for every
> hypervisor.
> h2. Background
> When enabling maintenance mode in a host, host state is put into
> 'PrepareForMaintenance' and running VMs are migrated into another host. After
> every VM is migrated, host goes to 'Maintenance' state.
> Checks are performed on ResourceManagerImpl.checkAndMaintan() method:
> * List VMs with host_id = HOST_ID
> * List VMs with last_host_id = HOST_ID and state=Migrating
> When both queries are empty, then the host can be put into Maintenance.
> When a VM is being migrated to DEST_HOST, its host_id column is set to
> DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then
> migration fails, host_id = last_host_id = ORIGIN_HOST
> h2. Issue
> This sequence:
> * Enable maintenance mode on ORIGIN_HOST
> * VMs start being migrated to a host, say DEST_HOST
> * checkAndMaintain() starts:
> ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are
> being migrated)
> ** Before the second check, one or more migrations fail
> ** Second check passes, however there are VMs running on the host as
> migrations have failed.
> * Host goes into Maintenance state.
> Screenshots attached, query executed on each case:
> select id, name, instance_name, state, host_id, last_host_id from vm_instance;
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401670#comment-16401670
]
ASF GitHub Bot commented on CLOUDSTACK-10326:
-
rafaelweingartner commented on a change in pull request #2493:
CLOUDSTACK-10326: Prevent hosts fall into Maintenance when there are running
VMs on it
URL: https://github.com/apache/cloudstack/pull/2493#discussion_r175036445
##
File path: server/src/com/cloud/resource/ResourceManagerImpl.java
##
@@ -1296,7 +1296,8 @@ public boolean checkAndMaintain(final long hostId) {
if (host.getType() != Host.Type.Storage) {
final List vos = _vmDao.listByHostId(hostId);
final List vosMigrating =
_vmDao.listVmsMigratingFromHost(hostId);
-if (vos.isEmpty() && vosMigrating.isEmpty()) {
+final List failedMigratedVms =
_vmDao.listRunningVmsByHostAndLastHostSameId(hostId);
+if (vos.isEmpty() && vosMigrating.isEmpty() &&
failedMigratedVms.isEmpty()) {
Review comment:
This also allows at least some unit testing
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
> Prevent hosts fall into Maintenance when there are running VMs on it
>
>
> Key: CLOUDSTACK-10326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
> Fix For: 4.11.1.0
>
> Attachments: CLOUDSTACK-10326-Debug.png,
> CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png,
> CLOUDSTACK-10326-MigrationFailed.png
>
>
> This issue was discovered, fixed and tested on KVM, but applies for every
> hypervisor.
> h2. Background
> When enabling maintenance mode in a host, host state is put into
> 'PrepareForMaintenance' and running VMs are migrated into another host. After
> every VM is migrated, host goes to 'Maintenance' state.
> Checks are performed on ResourceManagerImpl.checkAndMaintan() method:
> * List VMs with host_id = HOST_ID
> * List VMs with last_host_id = HOST_ID and state=Migrating
> When both queries are empty, then the host can be put into Maintenance.
> When a VM is being migrated to DEST_HOST, its host_id column is set to
> DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then
> migration fails, host_id = last_host_id = ORIGIN_HOST
> h2. Issue
> This sequence:
> * Enable maintenance mode on ORIGIN_HOST
> * VMs start being migrated to a host, say DEST_HOST
> * checkAndMaintain() starts:
> ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are
> being migrated)
> ** Before the second check, one or more migrations fail
> ** Second check passes, however there are VMs running on the host as
> migrations have failed.
> * Host goes into Maintenance state.
> Screenshots attached, query executed on each case:
> select id, name, instance_name, state, host_id, last_host_id from vm_instance;
--
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=16401597#comment-16401597 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373640788 @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401598#comment-16401598 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373640898 @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401592#comment-16401592 ] ASF GitHub Bot commented on CLOUDSTACK-10326: - blueorangutan commented on issue #2493: CLOUDSTACK-10326: Prevent hosts fall into Maintenance when there are running VMs on it URL: https://github.com/apache/cloudstack/pull/2493#issuecomment-373640030 @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Prevent hosts fall into Maintenance when there are running VMs on it > > > Key: CLOUDSTACK-10326 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.0 > > Attachments: CLOUDSTACK-10326-Debug.png, > CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png, > CLOUDSTACK-10326-MigrationFailed.png > > > This issue was discovered, fixed and tested on KVM, but applies for every > hypervisor. > h2. Background > When enabling maintenance mode in a host, host state is put into > 'PrepareForMaintenance' and running VMs are migrated into another host. After > every VM is migrated, host goes to 'Maintenance' state. > Checks are performed on ResourceManagerImpl.checkAndMaintan() method: > * List VMs with host_id = HOST_ID > * List VMs with last_host_id = HOST_ID and state=Migrating > When both queries are empty, then the host can be put into Maintenance. > When a VM is being migrated to DEST_HOST, its host_id column is set to > DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then > migration fails, host_id = last_host_id = ORIGIN_HOST > h2. Issue > This sequence: > * Enable maintenance mode on ORIGIN_HOST > * VMs start being migrated to a host, say DEST_HOST > * checkAndMaintain() starts: > ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are > being migrated) > ** Before the second check, one or more migrations fail > ** Second check passes, however there are VMs running on the host as > migrations have failed. > * Host goes into Maintenance state. > Screenshots attached, query executed on each case: > select id, name, instance_name, state, host_id, last_host_id from vm_instance; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401591#comment-16401591 ] ASF GitHub Bot commented on CLOUDSTACK-10326: - borisstoyanov commented on issue #2493: CLOUDSTACK-10326: Prevent hosts fall into Maintenance when there are running VMs on it URL: https://github.com/apache/cloudstack/pull/2493#issuecomment-373639940 @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Prevent hosts fall into Maintenance when there are running VMs on it > > > Key: CLOUDSTACK-10326 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.0 > > Attachments: CLOUDSTACK-10326-Debug.png, > CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png, > CLOUDSTACK-10326-MigrationFailed.png > > > This issue was discovered, fixed and tested on KVM, but applies for every > hypervisor. > h2. Background > When enabling maintenance mode in a host, host state is put into > 'PrepareForMaintenance' and running VMs are migrated into another host. After > every VM is migrated, host goes to 'Maintenance' state. > Checks are performed on ResourceManagerImpl.checkAndMaintan() method: > * List VMs with host_id = HOST_ID > * List VMs with last_host_id = HOST_ID and state=Migrating > When both queries are empty, then the host can be put into Maintenance. > When a VM is being migrated to DEST_HOST, its host_id column is set to > DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then > migration fails, host_id = last_host_id = ORIGIN_HOST > h2. Issue > This sequence: > * Enable maintenance mode on ORIGIN_HOST > * VMs start being migrated to a host, say DEST_HOST > * checkAndMaintain() starts: > ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are > being migrated) > ** Before the second check, one or more migrations fail > ** Second check passes, however there are VMs running on the host as > migrations have failed. > * Host goes into Maintenance state. > Screenshots attached, query executed on each case: > select id, name, instance_name, state, host_id, last_host_id from vm_instance; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401590#comment-16401590 ] ASF GitHub Bot commented on CLOUDSTACK-10326: - blueorangutan commented on issue #2493: CLOUDSTACK-10326: Prevent hosts fall into Maintenance when there are running VMs on it URL: https://github.com/apache/cloudstack/pull/2493#issuecomment-373639692 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1785 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 > Prevent hosts fall into Maintenance when there are running VMs on it > > > Key: CLOUDSTACK-10326 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.0 > > Attachments: CLOUDSTACK-10326-Debug.png, > CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png, > CLOUDSTACK-10326-MigrationFailed.png > > > This issue was discovered, fixed and tested on KVM, but applies for every > hypervisor. > h2. Background > When enabling maintenance mode in a host, host state is put into > 'PrepareForMaintenance' and running VMs are migrated into another host. After > every VM is migrated, host goes to 'Maintenance' state. > Checks are performed on ResourceManagerImpl.checkAndMaintan() method: > * List VMs with host_id = HOST_ID > * List VMs with last_host_id = HOST_ID and state=Migrating > When both queries are empty, then the host can be put into Maintenance. > When a VM is being migrated to DEST_HOST, its host_id column is set to > DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then > migration fails, host_id = last_host_id = ORIGIN_HOST > h2. Issue > This sequence: > * Enable maintenance mode on ORIGIN_HOST > * VMs start being migrated to a host, say DEST_HOST > * checkAndMaintain() starts: > ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are > being migrated) > ** Before the second check, one or more migrations fail > ** Second check passes, however there are VMs running on the host as > migrations have failed. > * Host goes into Maintenance state. > Screenshots attached, query executed on each case: > select id, name, instance_name, state, host_id, last_host_id from vm_instance; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401572#comment-16401572 ] ASF GitHub Bot commented on CLOUDSTACK-10326: - DaanHoogland commented on a change in pull request #2493: CLOUDSTACK-10326: Prevent hosts fall into Maintenance when there are running VMs on it URL: https://github.com/apache/cloudstack/pull/2493#discussion_r175018050 ## File path: engine/schema/src/com/cloud/vm/dao/VMInstanceDao.java ## @@ -150,4 +150,9 @@ VMInstanceVO findVMByHostNameInZone(String hostName, long zoneId); boolean isPowerStateUpToDate(long instanceId); + +/** + * List running VMs which host and lastHost id are the same Review comment: forgot a 'for' in the sentence 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 > Prevent hosts fall into Maintenance when there are running VMs on it > > > Key: CLOUDSTACK-10326 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.0 > > Attachments: CLOUDSTACK-10326-Debug.png, > CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png, > CLOUDSTACK-10326-MigrationFailed.png > > > This issue was discovered, fixed and tested on KVM, but applies for every > hypervisor. > h2. Background > When enabling maintenance mode in a host, host state is put into > 'PrepareForMaintenance' and running VMs are migrated into another host. After > every VM is migrated, host goes to 'Maintenance' state. > Checks are performed on ResourceManagerImpl.checkAndMaintan() method: > * List VMs with host_id = HOST_ID > * List VMs with last_host_id = HOST_ID and state=Migrating > When both queries are empty, then the host can be put into Maintenance. > When a VM is being migrated to DEST_HOST, its host_id column is set to > DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then > migration fails, host_id = last_host_id = ORIGIN_HOST > h2. Issue > This sequence: > * Enable maintenance mode on ORIGIN_HOST > * VMs start being migrated to a host, say DEST_HOST > * checkAndMaintain() starts: > ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are > being migrated) > ** Before the second check, one or more migrations fail > ** Second check passes, however there are VMs running on the host as > migrations have failed. > * Host goes into Maintenance state. > Screenshots attached, query executed on each case: > select id, name, instance_name, state, host_id, last_host_id from vm_instance; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401570#comment-16401570
]
ASF GitHub Bot commented on CLOUDSTACK-10326:
-
DaanHoogland commented on a change in pull request #2493: CLOUDSTACK-10326:
Prevent hosts fall into Maintenance when there are running VMs on it
URL: https://github.com/apache/cloudstack/pull/2493#discussion_r175018858
##
File path: server/src/com/cloud/resource/ResourceManagerImpl.java
##
@@ -1296,7 +1296,8 @@ public boolean checkAndMaintain(final long hostId) {
if (host.getType() != Host.Type.Storage) {
final List vos = _vmDao.listByHostId(hostId);
final List vosMigrating =
_vmDao.listVmsMigratingFromHost(hostId);
-if (vos.isEmpty() && vosMigrating.isEmpty()) {
+final List failedMigratedVms =
_vmDao.listRunningVmsByHostAndLastHostSameId(hostId);
+if (vos.isEmpty() && vosMigrating.isEmpty() &&
failedMigratedVms.isEmpty()) {
Review comment:
So this condition means
private boolean allMigrationWorkDone(){
final List vos = _vmDao.listByHostId(hostId);
final List vosMigrating =
_vmDao.listVmsMigratingFromHost(hostId);
final List failedMigratedVms =
_vmDao.listRunningVmsByHostAndLastHostSameId(hostId);
return vos.isEmpty() && vosMigrating.isEmpty() &&
failedMigratedVms.isEmpty();
}
let's create that method
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
> Prevent hosts fall into Maintenance when there are running VMs on it
>
>
> Key: CLOUDSTACK-10326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.11.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Major
> Fix For: 4.11.1.0
>
> Attachments: CLOUDSTACK-10326-Debug.png,
> CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png,
> CLOUDSTACK-10326-MigrationFailed.png
>
>
> This issue was discovered, fixed and tested on KVM, but applies for every
> hypervisor.
> h2. Background
> When enabling maintenance mode in a host, host state is put into
> 'PrepareForMaintenance' and running VMs are migrated into another host. After
> every VM is migrated, host goes to 'Maintenance' state.
> Checks are performed on ResourceManagerImpl.checkAndMaintan() method:
> * List VMs with host_id = HOST_ID
> * List VMs with last_host_id = HOST_ID and state=Migrating
> When both queries are empty, then the host can be put into Maintenance.
> When a VM is being migrated to DEST_HOST, its host_id column is set to
> DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then
> migration fails, host_id = last_host_id = ORIGIN_HOST
> h2. Issue
> This sequence:
> * Enable maintenance mode on ORIGIN_HOST
> * VMs start being migrated to a host, say DEST_HOST
> * checkAndMaintain() starts:
> ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are
> being migrated)
> ** Before the second check, one or more migrations fail
> ** Second check passes, however there are VMs running on the host as
> migrations have failed.
> * Host goes into Maintenance state.
> Screenshots attached, query executed on each case:
> select id, name, instance_name, state, host_id, last_host_id from vm_instance;
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401571#comment-16401571 ] ASF GitHub Bot commented on CLOUDSTACK-10326: - DaanHoogland commented on a change in pull request #2493: CLOUDSTACK-10326: Prevent hosts fall into Maintenance when there are running VMs on it URL: https://github.com/apache/cloudstack/pull/2493#discussion_r175018241 ## File path: engine/schema/src/com/cloud/vm/dao/VMInstanceDao.java ## @@ -150,4 +150,9 @@ VMInstanceVO findVMByHostNameInZone(String hostName, long zoneId); boolean isPowerStateUpToDate(long instanceId); + +/** + * List running VMs which host and lastHost id are the same + */ +List listRunningVmsByHostAndLastHostSameId(long hostId); Review comment: How about renaming the method to listRunningVmsByHostEqualsLastHost(), so we don't need the javadoc anymore? 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 > Prevent hosts fall into Maintenance when there are running VMs on it > > > Key: CLOUDSTACK-10326 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.0 > > Attachments: CLOUDSTACK-10326-Debug.png, > CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png, > CLOUDSTACK-10326-MigrationFailed.png > > > This issue was discovered, fixed and tested on KVM, but applies for every > hypervisor. > h2. Background > When enabling maintenance mode in a host, host state is put into > 'PrepareForMaintenance' and running VMs are migrated into another host. After > every VM is migrated, host goes to 'Maintenance' state. > Checks are performed on ResourceManagerImpl.checkAndMaintan() method: > * List VMs with host_id = HOST_ID > * List VMs with last_host_id = HOST_ID and state=Migrating > When both queries are empty, then the host can be put into Maintenance. > When a VM is being migrated to DEST_HOST, its host_id column is set to > DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then > migration fails, host_id = last_host_id = ORIGIN_HOST > h2. Issue > This sequence: > * Enable maintenance mode on ORIGIN_HOST > * VMs start being migrated to a host, say DEST_HOST > * checkAndMaintain() starts: > ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are > being migrated) > ** Before the second check, one or more migrations fail > ** Second check passes, however there are VMs running on the host as > migrations have failed. > * Host goes into Maintenance state. > Screenshots attached, query executed on each case: > select id, name, instance_name, state, host_id, last_host_id from vm_instance; -- 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=16401568#comment-16401568 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373633354 @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401566#comment-16401566 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373633268 @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401567#comment-16401567 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-373371916 @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401560#comment-16401560 ] ASF GitHub Bot commented on CLOUDSTACK-10326: - borisstoyanov commented on issue #2493: CLOUDSTACK-10326: Prevent hosts fall into Maintenance when there are running VMs on it URL: https://github.com/apache/cloudstack/pull/2493#issuecomment-373632019 @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 > Prevent hosts fall into Maintenance when there are running VMs on it > > > Key: CLOUDSTACK-10326 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.0 > > Attachments: CLOUDSTACK-10326-Debug.png, > CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png, > CLOUDSTACK-10326-MigrationFailed.png > > > This issue was discovered, fixed and tested on KVM, but applies for every > hypervisor. > h2. Background > When enabling maintenance mode in a host, host state is put into > 'PrepareForMaintenance' and running VMs are migrated into another host. After > every VM is migrated, host goes to 'Maintenance' state. > Checks are performed on ResourceManagerImpl.checkAndMaintan() method: > * List VMs with host_id = HOST_ID > * List VMs with last_host_id = HOST_ID and state=Migrating > When both queries are empty, then the host can be put into Maintenance. > When a VM is being migrated to DEST_HOST, its host_id column is set to > DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then > migration fails, host_id = last_host_id = ORIGIN_HOST > h2. Issue > This sequence: > * Enable maintenance mode on ORIGIN_HOST > * VMs start being migrated to a host, say DEST_HOST > * checkAndMaintain() starts: > ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are > being migrated) > ** Before the second check, one or more migrations fail > ** Second check passes, however there are VMs running on the host as > migrations have failed. > * Host goes into Maintenance state. > Screenshots attached, query executed on each case: > select id, name, instance_name, state, host_id, last_host_id from vm_instance; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10326) Prevent hosts fall into Maintenance when there are running VMs on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401562#comment-16401562 ] ASF GitHub Bot commented on CLOUDSTACK-10326: - blueorangutan commented on issue #2493: CLOUDSTACK-10326: Prevent hosts fall into Maintenance when there are running VMs on it URL: https://github.com/apache/cloudstack/pull/2493#issuecomment-373632134 @borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Prevent hosts fall into Maintenance when there are running VMs on it > > > Key: CLOUDSTACK-10326 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10326 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.0 > > Attachments: CLOUDSTACK-10326-Debug.png, > CLOUDSTACK-10326-InitialState.png, CLOUDSTACK-10326-Migrating.png, > CLOUDSTACK-10326-MigrationFailed.png > > > This issue was discovered, fixed and tested on KVM, but applies for every > hypervisor. > h2. Background > When enabling maintenance mode in a host, host state is put into > 'PrepareForMaintenance' and running VMs are migrated into another host. After > every VM is migrated, host goes to 'Maintenance' state. > Checks are performed on ResourceManagerImpl.checkAndMaintan() method: > * List VMs with host_id = HOST_ID > * List VMs with last_host_id = HOST_ID and state=Migrating > When both queries are empty, then the host can be put into Maintenance. > When a VM is being migrated to DEST_HOST, its host_id column is set to > DEST_HOST, last_host_id = ORIGIN_HOST and state = Migrating. If then > migration fails, host_id = last_host_id = ORIGIN_HOST > h2. Issue > This sequence: > * Enable maintenance mode on ORIGIN_HOST > * VMs start being migrated to a host, say DEST_HOST > * checkAndMaintain() starts: > ** First check passes (no VM with host_id = ORIGIN_HOST_ID as those are > being migrated) > ** Before the second check, one or more migrations fail > ** Second check passes, however there are VMs running on the host as > migrations have failed. > * Host goes into Maintenance state. > Screenshots attached, query executed on each case: > select id, name, instance_name, state, host_id, last_host_id from vm_instance; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
