Hide Forgot
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.
https://fedorahosted.org/pipermail/aeolus-devel/2011-December/007464.html
http://axiom.lab.eng.rdu.redhat.com/git/gitweb.cgi?p=aeolusproject/conductor.git;a=commit;h=3ecb7b56408814b0285497da222a9ac064715f01
3ecb7b5 in aeolus-conductor-0.8.0-12
Need test plan to test
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
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
assigning to Pushpesh
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.
[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