openstack team mailing list archive

[Eoghan Glynn <eglynn@xxxxxxxxxx>]

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