openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Thu, Nov 3, 2011 at 4:25 PM, Caitlin Bestler
<Caitlin.Bestler@xxxxxxxxxxx> wrote:
> Jay Pipes wrote:
>
>> Please find the updated 2nd Draft of the proposal here:
>
>> http://bit.ly/sA13yp
>
>> I will close out the first draft from comments.
>
>> Any and all feedback is most appreciated.
>
> In the 1.0 API determining how a Storage Server would support images was very simple.
> You were either a file server or a Swift server.
>
> So for a Storage vendor, supporting the 1.0 Image API was very simple, just support Swift.

I'm not quite following you... the API doesn't have anything to do
with the backend storage implementation, either in the 1.x or 2.0 API.
Could you elaborate a bit more so I understand what you are referring
to here?

> The 2.0 Image API introduces new capabilities,  but loses that straight-forward mapping to
> the underlying storage.
>
> Would it be possible to document this mapping?  It's not exactly the same thing as a user API,
> but it is an external interface that ideally should have similar stability.
>
> If no guarantees are available, just document that. "The underlying storage supporting an Image
> Server must provide a POSIX file service."

This is an implementation detail, IMHO, that does not need to be in
the API (and would make the API unnecessarily specific).

> But stronger statements like "each image will be represented as two Swift objects, one for the image
> Itself and one for its metadata" would help vendors configure systems for OpenStack deployment.

Well, let's separate implementation of Glance from the proposed Images
API 2.0 :) In Glance, we have a registry server that stores
information about image files and only image files are stored in
backend storage, not metadata about the image.

In the Images 2.0 API, I've deliberately removed implementation
specifics from the proposal. There is no mention of registries or
streaming servers anymore. There isn't any mention of Swift, S3, or
any other storage system, as those are implementation details.

Cheers,
-jay