Hi Folks, I've been looking into the (currently broken) EC2 CreateImage API support and just wanted to get a sanity check on the following line of reasoning:
- EC2 CreateImage should *only* apply to booted-from-volume nova servers, for fidelity with the EC2 limitation to EBS-based instances (i.e. should raise InvalidParameterValue when the API is applied to an instance-store style server). So my previous crack at this https://review.openstack.org/8532 was going completely in the wrong direction. - Normally, a snapshot of a bootable-volume is booted via the native API tooling with something like: nova boot --image IMAGE_ID --block-device-mapping vd[a-z]=SNAP_ID:snap::0 ... where AFAICS the IMAGE_ID is *only* used to determine the kernel and ramdisk IDs and is otherwise irrelevant. - The EC2 CreateImage on the other hand requires that a usable image ID be returned, not set of a volume snapshot IDs. - The resulting image should be bootable via EC2 RunInstances, but doesn't necessarily need to be portable, as it depends on local snapshot ID(s). Here a few different potential approaches to the creation of this image: 1. Create a "place-holder" image in glance with the image data being effectively empty, and the following properties set: * the imaged instance's kernel and ramdisk IDs * block device mapping containing the appropriate snapshot ID(s) so that we can boot from this image without providing additional context (such as the via nova boot --block-device-mapping option) 2. Extend the s3_image mapping logic such that an ami-* style ID can be mapped directly to a set of properties, snapshot IDs etc (so there would no image registration with glance). 3. Construct an AMI manifest containing the appropriate blockDeviceMapping and then leverage EC2 RegisterImage logic to create an AMI image. Some questions: - Does any of the above approaches to the image creation make sense? Option #3 in particular seems uneccessarily complex to me, and would I think require some reverse-engineering of the manifest format. I'm not sure there's much benefit in aping the EC2 image bundling/ registration approach given that the resulting image wouldn't be portable outside the current openstack deployment. However I may be missing something there ... - How should the lifecycle of the image and the corresponding snapshot(s) be intertwined? (e.g. should a deletion of the snapshot cause the corresponding image to be also deleted or marked unusable?) - Would a corresponding feature for the native API make sense? i.e. an equivalent of the nova createImage action that does not depend on the qemu-img command, but instead works for booted-from-vol servers. This would avoid the counter-intuitive use of an imageRef that's only used to grab the kernel and ramdisk IDs. Cheers, Eoghan _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp