Bug 767759 - Launching a deployable with multiple unique images can be stuck in "new"
Summary: Launching a deployable with multiple unique images can be stuck in "new"
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: aeolus-conductor
Version: 1.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
Assignee: Greg Blomquist
QA Contact: pushpesh sharma
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-14 20:17 UTC by Greg Blomquist
Modified: 2014-08-04 22:30 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-08-30 17:14:42 UTC
Embargoed:


Attachments (Terms of Use)

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 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


Note You need to log in before you can comment on or make changes to this bug.