openstack team mailing list archive
Mailing list archive
Re: Glance/Nova Snapshot Changes
On Thu, Dec 30, 2010 at 5:38 PM, Rick Harris <rick.harris@xxxxxxxxxxxxx> wrote:
> In developing Nova's instance snapshots, I've run into a little snag
> revolving around somed design decisions in both Nova and Glance. I have a
> plan that I'd like to move forward with ASAP, so please, if you see any
> problems or have any objections, raise them now.
> OpenStack's API divides calls into a "top-half" which returns quickly
> (compute/api.py) and a fire-and-forget "bottom-half" (compute/manager.py)
> which is long-running.
> The problems is that the image-create OpenStack API call (which maps to
> instance-snapshot) requires the image-metadata (id, name, status, etc) be
> returned up front. The current implementation, however, doesn't create the
> image in Glance until the snapshot is actually being uploaded which happens
> well after the OpenStack API "top-half" has returned.
> (* Aside: To facilitate caching, Glance treats image data as immutable, that
> is one reason we wanted to hold off on creating the Image record in Glance
> until the data was actually present. *)
> Since we cannot change the OpenStack API (yet), we'll need to modify both
> Nova and
> Glance to allow Images to exist *before* their data is available.
> Proposed Solution
> Here is my suggestion:
> * Glance images are given a status of 'queued', 'saving', 'active', or
> 'killed'. This field already exists-- I'm noting the statuses here
> we're going to start using them to enforce state. (Note: CloudServers
> a 'preparing' state which is no longer needed in the Nova-Glance
> * We modify Glance to allow the client to omit the image data on
> image-create (aka POST). When Glance detects this, it creates a record
> for the image in the registry, puts it into the 'queued' state, and then
> returns the image metadata.
> * We modify Glance to allow data to be uploaded in a subsequent PUT
> While the data is being uploaded, the image will be in the 'saving'
> if the operation completes sucessfully, it will go to 'active',
> it will go to 'killed'. Note, since we have an immutability constraint
> images, we should not allow image data to be updated once it exists, so,
> once the image goes 'active', subsequent PUT requests should fail with a
> 409 Conflict (or something similar). Also note, this is at odds somewhat
> with ReSTful semantics since a PUT in this case (when image data is
> present in the request body) is no longer idempotent. If we can think of
> a better way, I'm all ears, however, for now I think the tradeoff is
> * We modify OpenStack API image-create "top-half" to call
> ImageService.create which will POST to Glance without the image data. We
> will then return the image-metadata (with the image in a 'queued' state)
> to the callee. The "top-half" will then pass the "image_id" to the
> "bottom-half" which can upload the data into the specified image.
> * Modify Glance XenServer plugin to accept the image_id as an argument and
> to PUT to that resource.
This is a good plan. I fully support you.
> Also, Glance now has Python bindings in the form of its 'client.py'. As part
> of this effort, I'm planning on modifying ImageService::Glance to use the
> Glance client. This will mean that Nova will require that Glance be
> on the same machine running nova-api in order to use the Glance service.
This is already a blueprint:
It's assigned to me, but I could use some help with getting that done
if you have some spare cycles...