Bug 795743

Summary: Architecture mismatch check for imported images
Product: [Retired] CloudForms Cloud Engine Reporter: Jan Provaznik <jprovazn>
Component: aeolus-conductorAssignee: Shveta <ssachdev>
Status: CLOSED ERRATA QA Contact: wes hayutin <whayutin>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 1.0.0CC: akarol, cpelland, deltacloud-maint, hbrock, mfojtik, ssachdev
Target Milestone: rcKeywords: Triaged
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 22:37:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
architecture_check none

Description Jan Provaznik 2012-02-21 12:46:48 UTC 
This ticket is derived from https://bugzilla.redhat.com/show_bug.cgi?id=747048

For imported images we don't check architecture because this info wasn't available before. If a user tries to launch an instance w/ architecture != image's architecture, this error message is displayed in conductor for EC2:
500 : Unhandled exception or status code (InvalidParameterValue: The requested
instance type's architecture (x86_64) does not match the architecture in the
manifest for ami-205fba49 (i386)
REQUEST=ec2.us-east-1.amazonaws.com:443/?AWSAccessKeyId=AKIAI2KPFDYVZKSRTJMQ&Action=RunInstances&AddressingType=public&ImageId=ami-205fba49&InstanceType=c1.xlarge&KeyName=fedora_image_4_fedora-image-4_1329383822_key_70159176630200&MaxCount=1&MinCount=1&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2012-02-16T09%3A17%3A03.000Z&Version=2010-08-31&Signature=AbC96qH%2BV52%2BfdRltqc%2BVV9zMLYSF64edJqM4bclKE0%3D
REQUEST ID=fc89b5b6-56ae-466e-8fec-806cae17804a )

We could avoid this by checking architecture for imported images:
With new DC API, we can fetch hw profiles valid for an image. HW profile contains architecture info so we could save it when importing an image.

Nit: for our builds, arch info is saved in template, for imported images we don't create template at all, but we could save architecture as image's attribute in warehouse.
Comment 1 Michal Fojtik 2012-02-21 12:56:31 UTC 
Deltacloud API report the 'architecture' for all images. Warehouse should be aware of this and perform a check to DC when importing new image.
Comment 2 Matt Wagner 2012-02-21 14:42:57 UTC 
It looks like it's easy to detect architecture, but I'm still mulling over the best way to store this information. We specifically use the lack of a template on a valid image as an indication that the image is imported. I think I'll probably do what Jan proposes and just store the attribute directly on an image, but I'm not terribly eager to go monkeying around with the image models too much.
Comment 3 Matt Wagner 2012-02-24 19:53:57 UTC 
On list! http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-February/009153.html and child
Comment 4 Matt Wagner 2012-02-28 16:35:52 UTC 
Re-sent in response to some excellent feedback from jprovazn: http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-February/009226.html
Comment 5 Matt Wagner 2012-02-29 14:50:07 UTC 
Pushed.

aeolus-image rubygem:
 master: 57e07e9f583f36278bb7d72054c8dbf915789cb8
 0.3-maint: a3bf942e06616981d7791189dd2b7c7cee9cb837

conductor:
 master: f953ee07b6e535379a0cfb202c0bac76fff36d91, 23b0f5b057ba4dded17847a81df90fca2e3f29fa
 0.9-maint: 87bd40b46a471be7483cdbce65c5dc03a262567b, 8f674f582d193c7164efc8a1ee1cf9aba80553d1
Comment 7 Shveta 2012-03-07 12:31:57 UTC 
Created attachment 568278 [details]
architecture_check


Not fixed  "fedora-image400 : InvalidParameterValue: The requested instance type's architecture (x86_64) does not match the architecture in the manifest for ami-205fba49 (i386)"


rpm -qa|grep aeolus
aeolus-configure-2.5.0-18.el6.noarch
aeolus-conductor-doc-0.8.0-41.el6.noarch
rubygem-aeolus-cli-0.3.0-13.el6.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch
aeolus-conductor-daemons-0.8.0-41.el6.noarch
aeolus-conductor-0.8.0-41.el6.noarch
aeolus-all-0.8.0-41.el6.noarch
Comment 8 errata-xmlrpc 2012-05-15 22:37:33 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