Bug 767759

Summary: Launching a deployable with multiple unique images can be stuck in "new"
Product: [Retired] CloudForms Cloud Engine Reporter: Greg Blomquist <gblomqui>
Component: aeolus-conductorAssignee: Greg Blomquist <gblomqui>
Status: CLOSED CURRENTRELEASE QA Contact: pushpesh sharma <psharma>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 1.0.0CC: akarol, bbandari, deltacloud-maint, slinaber, 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-08-30 17:14:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Greg Blomquist 2011-12-14 20:17:09 UTC 
Description of problem:

When launching a multi-instance deployment with services from a deployable that references multiple unique image UUIDs, conductor will fail to launch and leave the deployment instances in a "new" state.

The matching logic attempts to collect a set of "match" objects by finding the intersection of "match" objects for all the instances.  The problem is that the "match" objects are not comparable in this way.  Instead the matrix of information needs to be translated into another structure to allow the data to be compared meaningfully against each other.

This is essentially the data structures being compared:

instance1 => 
  match1(provider_account1, provider_image1, hardware_profile1),
  match2(provider_account2, provider_image2, hardware_profile1)
instance2 => 
  match3(provider_account1, provider_image3, hardward_profile2)
instance3 => 
  match4(provider_account1, provider_image4, hardward_profile1),
  match5(provider_account2, provider_image5, hardward_profile1)

...to determine if the three instances can be launched in provider_account1.

If the data structures could be translated into:

provider_account1 =>
  instance1 => [match1],
  instance2 => [match3],
  instance3 => [match4]
provider_account2 =>
  instance1 => [match2],
  instance3 => [match5]

...then, it becomes immediately evident (and much easier to decipher in code) that provider_account1 has provider_images (i.e., "matches") for each launching instance.  While provider_account2 cannot launch all the instances.
Comment 1 Greg Blomquist 2011-12-14 20:26:45 UTC 
https://fedorahosted.org/pipermail/aeolus-devel/2011-December/007464.html
Comment 2 Greg Blomquist 2012-01-25 19:51:28 UTC 
http://axiom.lab.eng.rdu.redhat.com/git/gitweb.cgi?p=aeolusproject/conductor.git;a=commit;h=3ecb7b56408814b0285497da222a9ac064715f01
Comment 3 Steve Linabery 2012-01-26 16:46:33 UTC 
3ecb7b5 in aeolus-conductor-0.8.0-12
Comment 4 Shveta 2012-03-02 13:08:01 UTC 
Need test plan to test
Comment 5 Greg Blomquist 2012-03-22 15:36:34 UTC 
Overview of testing procedure:

As long as a deployable with two (or more) unique image IDs can be launched, then this bug is verified.

1. build image for first template (any template will do)
2. build image for another template (any template other than that used in step 1 will do)
3. push both images to a provider account
4. create deployable that will launch two assemblies; 
  - assembly 1 should reference image built in step 1
  - assembly 2 should reference image built in step 2
5. launch the deployable

Hope that helps
Comment 6 Greg Blomquist 2012-03-22 16:20:30 UTC 
More details on testing.  Dajo and I talked on IRC about how to test the negative scenarios as well.  Here's what we came up with:

Prereq:
1. Create ec2 provider account in conductor
2. Create rhev provider account in conductor
3. Build image from template 1 for both providers
4. Build image from template 2 for both providers
5. Create deployable that references templates 1 & 2 in assemblies
6. Create a realm mapped to ec2 provider account
7. Create a realm mapped to rhev provider account

Test 1:
1. Push both images to ec2
2. Launch deployable
3. Select ec2 realm during launch
Result: The deployment should successfully launch in ec2

Test 2:
1. Push one image to rhev
2. Launch deployable
3. Select rhev realm during launch
Result: An error/warning indicating that all of the images are not pushed to rhev
Comment 7 wes hayutin 2012-03-30 19:02:02 UTC 
assigning to Pushpesh
Comment 8 pushpesh sharma 2012-04-03 04:55:40 UTC 
Verified a Application(Deployable) with two different Image Id.Verified Application Blueprint looks like:-

<?xml version="1.0"?>
<deployable version="1.0" name="multi-assemblies">
  <description/>
  <assemblies>
    <assembly hwp="small-x86_64" name="RHEL6-2">
      <image id="6ae16f1c-7cd2-11e1-9a08-00215e20316a"/>
    </assembly>
    <assembly hwp="small-x86_64" name="rhel6">
      <image id="8faeba18-7cc6-11e1-9a08-00215e20316a"/>
    </assembly>
  </assemblies>
</deployable>


Application is launched successfully with Amazon-Ec2.
Comment 9 pushpesh sharma 2012-04-03 04:57:12 UTC 
[root@qe-blade-01 ~]# rpm -qa|grep aeolus
aeolus-conductor-doc-0.8.7-1.el6.noarch
aeolus-configure-2.5.2-1.el6.noarch
aeolus-conductor-0.8.7-1.el6.noarch
rubygem-aeolus-cli-0.3.1-1.el6.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch
aeolus-conductor-daemons-0.8.7-1.el6.noarch
aeolus-all-0.8.7-1.el6.noarch