Bug 773407

Summary: Launching, w/ a realm w/ multiple providers fails
Product: [Retired] CloudForms Cloud Engine Reporter: wes hayutin <whayutin>
Component: aeolus-conductorAssignee: Scott Seago <sseago>
Status: CLOSED ERRATA QA Contact: Rehana <redakkan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 1.0.0CC: akarol, deltacloud-maint, redakkan, ssachdev
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-15 21:39:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
ss1
none
ss2
none
imagepushed to multiple providers
none
rhevm priority
none
vsphere priority
none
multi-provider cluster none

Description wes hayutin 2012-01-11 18:44:58 UTC
Description of problem:

recreate:
1. create a realm for vsphere
2. create a realm for rhevm
3. create a third realm  that maps both providers

1. have a template built and pushed to both rhevm and vshpere
2. launch the deployable w/ the third realm.. in #3

results..
unhandled exception

expected result
either the image is launched w/ the provider w/ the higher priority or a proper error message why its not..

see screenshots

Comment 1 wes hayutin 2012-01-11 18:45:38 UTC
Created attachment 552194 [details]
ss1

Comment 2 wes hayutin 2012-01-11 18:46:00 UTC
Created attachment 552195 [details]
ss2

Comment 3 wes hayutin 2012-01-11 18:46:12 UTC
[root@qeblade32 yum.repos.d]# rpm -qa | grep aeolus
aeolus-configure-2.5.0-3.el6.noarch
rubygem-aeolus-image-0.3.0-2.el6.noarch
aeolus-conductor-0.8.0-5.el6.noarch
rubygem-aeolus-cli-0.3.0-3.el6.noarch
aeolus-conductor-doc-0.8.0-5.el6.noarch
aeolus-conductor-daemons-0.8.0-5.el6.noarch
aeolus-all-0.8.0-5.el6.noarch

Comment 4 wes hayutin 2012-01-11 18:46:38 UTC
In this case.. vsphere had a priority=1, rhevm =2

Comment 5 wes hayutin 2012-01-12 16:34:27 UTC
adding to ce-sprint

Comment 6 wes hayutin 2012-01-12 16:40:44 UTC
removing ce-sprint-next tracker

Comment 7 Scott Seago 2012-01-23 16:14:58 UTC
Do you still have the logs available? The exception text looks like it points to a bug in the code ("undefined method 'empty?' for nil:NilClass") -- we have something that's nil that we expect to be an array -- the log would make it a lot easier to pinpoint. /var/log/aeolus-conductor/rails.log would be the likely place to see a corresponding stacktrace.

Comment 8 Scott Seago 2012-01-23 16:18:18 UTC
Also, it looks like this and 773410 are reporting essentially the same setup. The only difference is that here you're creating two additional realms (that you're not using at launch). With the latest comment on 773410 indicating that it's not repeatable, I'm wondering about this one as well.

Comment 9 wes hayutin 2012-01-23 17:03:38 UTC
will try to recreate

Comment 11 Rehana 2012-02-24 07:42:46 UTC
I was unable to reproduce the same. The instance came to running state (instance_running.jpg)

Screen shot attached:
1. Image pushed to multiple providers.png
2. rhevm priority.png
3. vsphere priority.png
4. multi-provider cluster.png


additional info:
[root@ibm-ls21-04 ~]# rpm -qa | grep aeolus
aeolus-conductor-daemons-0.8.0-35.el6.noarch
aeolus-conductor-0.8.0-35.el6.noarch
aeolus-configure-2.5.0-15.el6.noarch
aeolus-conductor-doc-0.8.0-35.el6.noarch
rubygem-aeolus-cli-0.3.0-10.el6.noarch
aeolus-all-0.8.0-35.el6.noarch
rubygem-aeolus-image-0.3.0-9.el6.noarch

Comment 12 Rehana 2012-02-24 07:43:39 UTC
Created attachment 565514 [details]
imagepushed to multiple providers

Comment 13 Rehana 2012-02-24 07:44:23 UTC
Created attachment 565515 [details]
rhevm priority

Comment 14 Rehana 2012-02-24 07:46:08 UTC
Created attachment 565517 [details]
vsphere priority

Comment 15 Rehana 2012-02-24 07:47:08 UTC
Created attachment 565519 [details]
multi-provider cluster

Comment 16 errata-xmlrpc 2012-05-15 21:39:28 UTC
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.

http://rhn.redhat.com/errata/RHEA-2012-0583.html