Description of problem: During testing RHOS Infrastructure integration, I fleeced an image in deployed overcloud and when I wanted to see the list of init processes, it threw an error. Version-Release number of selected component (if applicable): 5.4.0.0.19 How reproducible: always Steps to Reproduce: 1. Fleece an OpenStack image (Images by Provider accordion) 2. Wait for the process to finish 3. Go to the image's Summary screen 4. Click Init processes in the Configuration section Actual results: undefined method `name' for nil:NilClass [vm_cloud/explorer] Expected results: List of init processes displayed. Additional info: It is possible that you might need the Openstack provider being deployed via Undercloud. I can provide credentials for our QE setup or even the appliance which has everything configured.
Rich, please look at this. Not sure if this should be only fleecing, or if it's really webUI. Thanks
*** Bug 1223389 has been marked as a duplicate of this bug. ***
New commit detected on manageiq/master: https://github.com/ManageIQ/manageiq/commit/6a6dd913837f78f5750d0386f4f3efe6b331c174 commit 6a6dd913837f78f5750d0386f4f3efe6b331c174 Author: Martin Hradil <mhradil> AuthorDate: Tue May 19 18:09:03 2015 +0000 Commit: Martin Hradil <mhradil> CommitDate: Wed May 27 16:37:38 2015 +0000 Make show_association use controller_to_model when retrieving @record This makes linux_initprocesses (and others) load from VmOrTemplate, not VmCloud - without it, /vm_cloud/linux_initprocesses/119 tries to load VmCloud(id=119) and not VmOrTemplate(id=119) in CiProcessing#show_association. This has been broken since ec1389e which unified all the show_association methods, without the special @record load handling that was present in VmCommon. Without it, a load from VmCloud is attempted instead of VmOrTemplate, and fails. This likely affects *all* show_association calls made from vm_common - Running Processes, Registry Entries, Advanced Settings, Init Processes, Win32 Services, Kernel Drivers, File System Drivers, Files and Security Groups. https://bugzilla.redhat.com/show_bug.cgi?id=1211665 vmdb/app/controllers/application_controller/ci_processing.rb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
*** Bug 1229362 has been marked as a duplicate of this bug. ***
New commit detected on cfme/5.4.z: https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=3ba1071a1774866bf6ea75e6a1ee4fcb52c6a585 commit 3ba1071a1774866bf6ea75e6a1ee4fcb52c6a585 Author: Martin Hradil <mhradil> AuthorDate: Tue May 19 18:09:03 2015 +0000 Commit: Martin Hradil <mhradil> CommitDate: Tue Jun 9 13:45:58 2015 +0000 Make show_association use controller_to_model when retrieving @record This makes linux_initprocesses (and others) load from VmOrTemplate, not VmCloud - without it, /vm_cloud/linux_initprocesses/119 tries to load VmCloud(id=119) and not VmOrTemplate(id=119) in CiProcessing#show_association. This has been broken since ec1389e which unified all the show_association methods, without the special @record load handling that was present in VmCommon. Without it, a load from VmCloud is attempted instead of VmOrTemplate, and fails. This likely affects *all* show_association calls made from vm_common - Running Processes, Registry Entries, Advanced Settings, Init Processes, Win32 Services, Kernel Drivers, File System Drivers, Files and Security Groups. https://bugzilla.redhat.com/show_bug.cgi?id=1211665 (cherry picked from commit 6a6dd913837f78f5750d0386f4f3efe6b331c174) vmdb/app/controllers/application_controller/ci_processing.rb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
New commit detected on cfme/5.4.z: https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=950098c0410e948f0880f8bfe49de53fdadb5648 commit 950098c0410e948f0880f8bfe49de53fdadb5648 Merge: 7daa1a8 3ba1071 Author: Martin Povolny <mpovolny> AuthorDate: Wed Jun 10 02:25:18 2015 -0400 Commit: Martin Povolny <mpovolny> CommitDate: Wed Jun 10 02:25:18 2015 -0400 Merge branch 'bz1211665' into '5.4.z' Make show_association use controller_to_model when retrieving @record This makes linux_initprocesses (and others) load from VmOrTemplate, not VmCloud - without it, /vm_cloud/linux_initprocesses/119 tries to load VmCloud(id=119) and not VmOrTemplate(id=119) in CiProcessing#show_association. This has been broken since ec1389e which unified all the show_association methods, without the special @record load handling that was present in VmCommon. Without it, a load from VmCloud is attempted instead of VmOrTemplate, and fails. This likely affects *all* show_association calls made from vm_common - Running Processes, Registry Entries, Advanced Settings, Init Processes, Win32 Services, Kernel Drivers, File System Drivers, Files and Security Groups. https://bugzilla.redhat.com/show_bug.cgi?id=1211665 (cherry picked from commit 6a6dd913837f78f5750d0386f4f3efe6b331c174) See merge request !117 vmdb/app/controllers/application_controller/ci_processing.rb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
New commit detected on cfme/5.3.z: https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=1bbc0a6981c3a0f02943c02a89805eb2a408e4d3 commit 1bbc0a6981c3a0f02943c02a89805eb2a408e4d3 Author: Martin Hradil <mhradil> AuthorDate: Tue May 19 18:09:03 2015 +0000 Commit: Martin Hradil <mhradil> CommitDate: Wed Jul 15 15:19:55 2015 +0000 Make show_association use controller_to_model when retrieving @record This makes linux_initprocesses (and others) load from VmOrTemplate, not VmCloud - without it, /vm_cloud/linux_initprocesses/119 tries to load VmCloud(id=119) and not VmOrTemplate(id=119) in CiProcessing#show_association. This has been broken since ec1389e which unified all the show_association methods, without the special @record load handling that was present in VmCommon. Without it, a load from VmCloud is attempted instead of VmOrTemplate, and fails. This likely affects *all* show_association calls made from vm_common - Running Processes, Registry Entries, Advanced Settings, Init Processes, Win32 Services, Kernel Drivers, File System Drivers, Files and Security Groups. https://bugzilla.redhat.com/show_bug.cgi?id=1211665 (cherry picked from commit 6a6dd913837f78f5750d0386f4f3efe6b331c174) (cherry picked from commit 3ba1071a1774866bf6ea75e6a1ee4fcb52c6a585) Cherry-picked without the condition=nil param to show_association. vmdb/app/controllers/application_controller/ci_processing.rb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
New commit detected on cfme/5.3.z: https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=d08d7445ebb21d6cf0c9ad56fba69bb39f6653c2 commit d08d7445ebb21d6cf0c9ad56fba69bb39f6653c2 Merge: a80ec6a 1bbc0a6 Author: Dan Clarizio <dclarizi> AuthorDate: Wed Jul 15 13:49:21 2015 -0400 Commit: Dan Clarizio <dclarizi> CommitDate: Wed Jul 15 13:49:21 2015 -0400 Merge branch 'bz1214138' into '5.3.z' Make show_association use controller_to_model when retrieving @record This makes linux_initprocesses (and others) load from VmOrTemplate, not VmCloud - without it, /vm_cloud/linux_initprocesses/119 tries to load VmCloud(id=119) and not VmOrTemplate(id=119) in CiProcessing#show_association. This has been broken since ec1389e which unified all the show_association methods, without the special @record load handling that was present in VmCommon. Without it, a load from VmCloud is attempted instead of VmOrTemplate, and fails. This likely affects *all* show_association calls made from vm_common - Running Processes, Registry Entries, Advanced Settings, Init Processes, Win32 Services, Kernel Drivers, File System Drivers, Files and Security Groups. https://bugzilla.redhat.com/show_bug.cgi?id=1211665 (cherry picked from commit 6a6dd913837f78f5750d0386f4f3efe6b331c174) (cherry picked from commit 3ba1071a1774866bf6ea75e6a1ee4fcb52c6a585) Cherry-picked without the condition=nil param to show_association. See merge request !177 vmdb/app/controllers/application_controller/ci_processing.rb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Verification blocked by BZ#1264327
I applied my patch for 1264327 (https://github.com/ManageIQ/manageiq/pull/4810) on a 5.5.0.5 appliance and I was able to obtain the SSA data. Clicking the init processes then correctly showed the screen with fleeced init processes. @dajo, do you think I can move this to VERIFIED even without waiting for the fleecing bug to be resolved because I was able to obtain the data using the patch?
Verified in 5.5.0.6 as said above. The bug blocker is not closed yet, but the issue was already fixed.
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://access.redhat.com/errata/RHSA-2015:2551