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.
Deltacloud API report the 'architecture' for all images. Warehouse should be aware of this and perform a check to DC when importing new image.
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.
On list! http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-February/009153.html and child
Re-sent in response to some excellent feedback from jprovazn: http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-February/009226.html
Pushed. aeolus-image rubygem: master: 57e07e9f583f36278bb7d72054c8dbf915789cb8 0.3-maint: a3bf942e06616981d7791189dd2b7c7cee9cb837 conductor: master: f953ee07b6e535379a0cfb202c0bac76fff36d91, 23b0f5b057ba4dded17847a81df90fca2e3f29fa 0.9-maint: 87bd40b46a471be7483cdbce65c5dc03a262567b, 8f674f582d193c7164efc8a1ee1cf9aba80553d1
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
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