Description of problem: When trying to power off a VM from the global UI the response was that it was in progress but after waiting nothing ever happened. Same result for power on. However, the action succeeds from the Regional UI. Version-Release number of selected component (if applicable): 5.6.3 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
https://github.com/ManageIQ/manageiq/pull/13129
This doesn't really apply to future or 5.7 as this use case will be covered by central admin for those versions. https://github.com/ManageIQ/manageiq/pull/13129 is a PR to the Darga branch which will allow us to use the built in VM power ops in the next 5.6 errata release. Because of that I am changing the flags and target release to reflect that this fix is only included in the 5.6.z stream releases.
New commit detected on ManageIQ/manageiq/darga: https://github.com/ManageIQ/manageiq/commit/0d4305d35b613b9b60b736db10edef57287ec78d commit 0d4305d35b613b9b60b736db10edef57287ec78d Author: Nick Carboni <ncarboni> AuthorDate: Mon Dec 12 17:18:20 2016 -0500 Commit: Nick Carboni <ncarboni> CommitDate: Mon Dec 12 21:41:34 2016 -0500 Add VmOrTemplate.invoke_tasks_remote_queue This will allow us to determine which server runs the remote tasks. This is good because then we can limit the servers that need the remote API authentication stored on them. https://bugzilla.redhat.com/show_bug.cgi?id=1404023 app/models/vm_or_template.rb | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)
New commit detected on ManageIQ/manageiq/darga: https://github.com/ManageIQ/manageiq/commit/2cbb1bc2700b86105d925572b9e5cde04ccb04fd commit 2cbb1bc2700b86105d925572b9e5cde04ccb04fd Author: Nick Carboni <ncarboni> AuthorDate: Mon Dec 12 18:51:48 2016 -0500 Commit: Nick Carboni <ncarboni> CommitDate: Tue Dec 13 07:47:13 2016 -0500 Use the REST API for VM power operations This commit adds VmOrTemplate.invoke_api_task which uses the REST API to invoke a particular task on a group of VMs. We also add configuration keys for specifying the remote API user and password. These settings must be specified in the advanced settings page of the server with the User Interface role in the global region. These appliances will be used to route the requests to the remote appliance with the webservices role active. The password can be encrypted using the global region's v2_key https://bugzilla.redhat.com/show_bug.cgi?id=1404023 app/models/mixins/process_tasks_mixin.rb | 2 +- app/models/vm_or_template.rb | 53 +++++++++++++++++++++++++++++--- config/settings.yml | 4 +++ 3 files changed, 54 insertions(+), 5 deletions(-)
New commit detected on ManageIQ/manageiq/darga: https://github.com/ManageIQ/manageiq/commit/5f1e226832f3d57ca1f4d413bf791bd72799700a commit 5f1e226832f3d57ca1f4d413bf791bd72799700a Author: Nick Carboni <ncarboni> AuthorDate: Tue Dec 13 08:30:52 2016 -0500 Commit: Nick Carboni <ncarboni> CommitDate: Tue Dec 13 08:30:52 2016 -0500 Force the ids in invoke_tasks to be integers When selecting a power operation from the VM summary screen these ids come down as strings, but when selecting multiple from the VM grid view they come down as integers. https://bugzilla.redhat.com/show_bug.cgi?id=1404023 app/models/mixins/process_tasks_mixin.rb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Hey Leo, This was a last minute addition to 5.6 because we had a regression when moving from the SOAP to REST API. We used to support VM power ops from the global region when we had the SOAP API so this needed to be added back in with REST. To get this working you need to specify the :webservices => :remote_miq_api user (username) and password values in the global region's advanced settings for the server with the user interface role. The PR (https://github.com/ManageIQ/manageiq/pull/13129) should go into much more detail if you need more information.
thanks Nick. that helped a lot
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2017-0474.html