[jira] [Created] (CLOUDSTACK-9645) Add support for not restarting the management server after setup
Jeff Hair created CLOUDSTACK-9645: - Summary: Add support for not restarting the management server after setup Key: CLOUDSTACK-9645 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9645 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.9.0 Reporter: Jeff Hair Fix For: 4.10.0.0 Enhance the cloudstack-setup-management script to allow the ability to NOT restart the management server. Helps with systemd. This has been implemented already, but there was a bug with it where it would not properly respect the option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9644) Add bits field to template response
Jeff Hair created CLOUDSTACK-9644: - Summary: Add bits field to template response Key: CLOUDSTACK-9644 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9644 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.9.0 Reporter: Jeff Hair Fix For: 4.10.0.0 Enhance the list templates command to return the size of the template in bits. See: https://github.com/apache/cloudstack/pull/1622 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9643) Add OS info to list snapshots response
Jeff Hair created CLOUDSTACK-9643: - Summary: Add OS info to list snapshots response Key: CLOUDSTACK-9643 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9643 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.9.0 Reporter: Jeff Hair Fix For: 4.10.0.0 Add OS info to list snapshots response. See https://github.com/apache/cloudstack/pull/1618 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Hair updated CLOUDSTACK-9317: -- Description: The current behavior of enabling or disabling static NAT will call the apply IP associations method in the management server. The method is not thread-safe. If it's called from multiple threads, each thread will load up the list of public IPs in different states (add or revoke)--correct for the thread, but not correct overall. Depending on execution order on the virtual router, the router can end up with public IPs assigned to it that are not supposed to be on it anymore. When another account acquires the same IP, this of course leads to network problems. The problem has been in CS since at least 4.2, and likely affects all recently released versions. Affected version is set to 4.7.x because that's what we verified against. was:The current behavior of enabling or disabling static NAT will call the apply IP associations method in the management server. The method is not thread-safe. If it's called from multiple threads, each thread will load up the list of public IPs in different states (add or revoke)--correct for the thread, but not correct overall. Depending on execution order on the virtual router, the router can end up with public IPs assigned to it that are not supposed to be on it anymore. When another account acquires the same IP, this of course leads to network problems. > Disabling static NAT on many IPs can leave wrong IPs on the router > -- > > Key: CLOUDSTACK-9317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Virtual Router >Affects Versions: 4.7.0, 4.7.1, 4.7.2 >Reporter: Jeff Hair > > The current behavior of enabling or disabling static NAT will call the apply > IP associations method in the management server. The method is not > thread-safe. If it's called from multiple threads, each thread will load up > the list of public IPs in different states (add or revoke)--correct for the > thread, but not correct overall. Depending on execution order on the virtual > router, the router can end up with public IPs assigned to it that are not > supposed to be on it anymore. When another account acquires the same IP, this > of course leads to network problems. > The problem has been in CS since at least 4.2, and likely affects all > recently released versions. Affected version is set to 4.7.x because that's > what we verified against. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15206136#comment-15206136 ] Jeff Hair commented on CLOUDSTACK-9317: --- A pull request to fix this problem: https://github.com/apache/cloudstack/pull/1450 > Disabling static NAT on many IPs can leave wrong IPs on the router > -- > > Key: CLOUDSTACK-9317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Virtual Router >Affects Versions: 4.7.0, 4.7.1, 4.7.2 >Reporter: Jeff Hair > > The current behavior of enabling or disabling static NAT will call the apply > IP associations method in the management server. The method is not > thread-safe. If it's called from multiple threads, each thread will load up > the list of public IPs in different states (add or revoke)--correct for the > thread, but not correct overall. Depending on execution order on the virtual > router, the router can end up with public IPs assigned to it that are not > supposed to be on it anymore. When another account acquires the same IP, this > of course leads to network problems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
Jeff Hair created CLOUDSTACK-9317: - Summary: Disabling static NAT on many IPs can leave wrong IPs on the router Key: CLOUDSTACK-9317 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Virtual Router Affects Versions: 4.7.0, 4.7.1, 4.7.2 Reporter: Jeff Hair The current behavior of enabling or disabling static NAT will call the apply IP associations method in the management server. The method is not thread-safe. If it's called from multiple threads, each thread will load up the list of public IPs in different states (add or revoke)--correct for the thread, but not correct overall. Depending on execution order on the virtual router, the router can end up with public IPs assigned to it that are not supposed to be on it anymore. When another account acquires the same IP, this of course leads to network problems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9003) Make VM naming services injectable and in their own module
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15201243#comment-15201243 ] Jeff Hair commented on CLOUDSTACK-9003: --- The ticket can remain open. We have a more thorough solution on our fork of the repository which we submit in the coming weeks. > Make VM naming services injectable and in their own module > -- > > Key: CLOUDSTACK-9003 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9003 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Jeffrey Hair >Priority: Minor > > Proposal: Make the various classes/code that give VMs and other resources > hostnames, hypervisor guest names, and UUIDs into their classes as injectable > dependencies in their own module under the core or backend module. > This proposal originally only concerned the VirtualMachineName class and can > be broken down into several parts: > * Make the VirtualMachineName class an injectable dependency instead of being > full of static methods. > * Refactor the generateHostName method in UserVmManagerImpl to be backed by > an injectable service which generates host names. > * Move the UUIDManagerImpl from the core module to a new module (grouped with > the other 2 ideally). > Rationale: > * VirtualMachineName is one of the few remaining classes that has static > methods tangled like spaghetti throughout the code. This change will put it > in line with the rest of the management server codebase and opens the door to > extensibility. Which brings us to... > * Extensibility: The ultimate goal of this feature is to provide 3rd party > developers the option of changing default instance/resource naming policies. > Currently this is possible in a very limited fashion with the instance.name > global setting, but this proposal makes it much more extensible. > By moving the naming-related services (VirtualMachineName, UUIDManager, and > more as added/discovered) to their own module, the module can be excluded by > modules.properties and different ones substituted in. Alternatively, it could > use the adapter model that other classes use, and the user can configure > which adapters are active and also provide custom ones. > A good use case for this functionality is using a different style naming to > emulate other cloud providers such as AWS (i-abc123) or GCE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9280) System VM volumes cannot be deleted when there are no system VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137242#comment-15137242 ] Jeff Hair commented on CLOUDSTACK-9280: --- Pull request #1406 is the correct PR. #1405 was on the wrong base branch (master instead of 4.6). > System VM volumes cannot be deleted when there are no system VMs > > > Key: CLOUDSTACK-9280 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9280 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0, 4.7.0 >Reporter: Jeff Hair > > Scenario: When deleting a zone, everything under it must be removed. This > results in the system VMs being destroyed as there are no more hosts running. > The storage cleanup thread properly detects that there are volumes to be > deleted, but it cannot delete them because the endpoint selection fails with > "No remote endpoint to send DeleteCommand, check if host or ssvm is down?" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9280) System VM volumes cannot be deleted when there are no system VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15134374#comment-15134374 ] Jeff Hair commented on CLOUDSTACK-9280: --- This was discovered when trying to clean up zones completely. This problem goes all the way back to at least 4.2 it seems. In the case of 4.6+, the zone deletion will fail because it detects volumes still existing in the database. Removing the volumes in the database allows the zone to be deleted. We will file a pull request with a possible solution to this issue. I will likely implement some special "endpoint" that is only used in this specific case. Any other suggestions are most welcome. > System VM volumes cannot be deleted when there are no system VMs > > > Key: CLOUDSTACK-9280 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9280 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0, 4.7.0 >Reporter: Jeff Hair > > Scenario: When deleting a zone, everything under it must be removed. This > results in the system VMs being destroyed as there are no more hosts running. > The storage cleanup thread properly detects that there are volumes to be > deleted, but it cannot delete them because the endpoint selection fails with > "No remote endpoint to send DeleteCommand, check if host or ssvm is down?" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9280) System VM volumes cannot be deleted when there are no system VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Hair updated CLOUDSTACK-9280: -- Description: Scenario: When deleting a zone, everything under it must be removed. This results in the system VMs being destroyed as there are no more hosts running. The storage cleanup thread properly detects that there are volumes to be deleted, but it cannot delete them because the endpoint selection fails with "No remote endpoint to send DeleteCommand, check if host or ssvm is down?" was: Scenario: When deleting a zone, everything under it must be removed. This results in the system VMs being destroyed as there are no more hosts running. The storage cleanup thread properly detects that there are volumes to be deleted, but it cannot delete them because the endpoint selection fails with > System VM volumes cannot be deleted when there are no system VMs > > > Key: CLOUDSTACK-9280 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9280 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0, 4.7.0 >Reporter: Jeff Hair > > Scenario: When deleting a zone, everything under it must be removed. This > results in the system VMs being destroyed as there are no more hosts running. > The storage cleanup thread properly detects that there are volumes to be > deleted, but it cannot delete them because the endpoint selection fails with > "No remote endpoint to send DeleteCommand, check if host or ssvm is down?" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9280) System VM volumes cannot be deleted when there are no system VMs
Jeff Hair created CLOUDSTACK-9280: - Summary: System VM volumes cannot be deleted when there are no system VMs Key: CLOUDSTACK-9280 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9280 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.6.0, 4.7.0 Reporter: Jeff Hair Scenario: When deleting a zone, everything under it must be removed. This results in the system VMs being destroyed as there are no more hosts running. The storage cleanup thread properly detects that there are volumes to be deleted, but it cannot delete them because the endpoint selection fails with -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6467) User VM state listener publishes to event bus incompletely
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Hair updated CLOUDSTACK-6467: -- Fix Version/s: 4.5.0 > User VM state listener publishes to event bus incompletely > -- > > Key: CLOUDSTACK-6467 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6467 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0, 4.3.0, 4.4.0, 4.5.0 > Environment: CentOS 6.5 >Reporter: Jeff Hair > Labels: easyfix, patch > Fix For: 4.5.0 > > > The UserVMStateListener is responsible for publishing resource state > transition events and usage events for virtual machines. It has an issue > where, from the point of view of any listener bound on the event bus, it > publishes resource state transition events for user VMs twice and only > publishes events for system VMs (e.g. virtual routers) once, but before the > state transition happens. Usage events are unaffected. > This is because of two issues: > 1. The publishOnEventBusMethod receives a status parameter to determine > whether the event is pre- or post-transition. It ignores this parameter when > publishing. > 2. Only pre-transition events are published for system VMs like routers. This > means there is no reliable way to act on a state transition event for system > VMs if we are interested in doing something AFTER they have changed the state. > The easiest solution to these issues is to move the the publishOnEventBus > call in postStateTransitionEvent to before it returns for non-user VMs, and > then also add the status string into the event description map when > publishing to the event bus. > I've also submitted a patch for this change to review board. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6467) User VM state listener publishes to event bus incompletely
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Hair resolved CLOUDSTACK-6467. --- Resolution: Fixed Fix pushed to master branch as: 9c4de764f74bffd5cd547f8514d4a6897fb961c2 > User VM state listener publishes to event bus incompletely > -- > > Key: CLOUDSTACK-6467 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6467 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0, 4.3.0, 4.4.0, 4.5.0 > Environment: CentOS 6.5 >Reporter: Jeff Hair > Labels: easyfix, patch > Fix For: 4.5.0 > > > The UserVMStateListener is responsible for publishing resource state > transition events and usage events for virtual machines. It has an issue > where, from the point of view of any listener bound on the event bus, it > publishes resource state transition events for user VMs twice and only > publishes events for system VMs (e.g. virtual routers) once, but before the > state transition happens. Usage events are unaffected. > This is because of two issues: > 1. The publishOnEventBusMethod receives a status parameter to determine > whether the event is pre- or post-transition. It ignores this parameter when > publishing. > 2. Only pre-transition events are published for system VMs like routers. This > means there is no reliable way to act on a state transition event for system > VMs if we are interested in doing something AFTER they have changed the state. > The easiest solution to these issues is to move the the publishOnEventBus > call in postStateTransitionEvent to before it returns for non-user VMs, and > then also add the status string into the event description map when > publishing to the event bus. > I've also submitted a patch for this change to review board. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6467) User VM state listener publishes to event bus incompletely
Jeff Hair created CLOUDSTACK-6467: - Summary: User VM state listener publishes to event bus incompletely Key: CLOUDSTACK-6467 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6467 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0, 4.3.0, 4.4.0, 4.5.0 Environment: CentOS 6.5 Reporter: Jeff Hair The UserVMStateListener is responsible for publishing resource state transition events and usage events for virtual machines. It has an issue where, from the point of view of any listener bound on the event bus, it publishes resource state transition events for user VMs twice and only publishes events for system VMs (e.g. virtual routers) once, but before the state transition happens. Usage events are unaffected. This is because of two issues: 1. The publishOnEventBusMethod receives a status parameter to determine whether the event is pre- or post-transition. It ignores this parameter when publishing. 2. Only pre-transition events are published for system VMs like routers. This means there is no reliable way to act on a state transition event for system VMs if we are interested in doing something AFTER they have changed the state. The easiest solution to these issues is to move the the publishOnEventBus call in postStateTransitionEvent to before it returns for non-user VMs, and then also add the status string into the event description map when publishing to the event bus. I've also submitted a patch for this change to review board. -- This message was sent by Atlassian JIRA (v6.2#6252)
