openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On 04/07/2012 06:13 PM, Justin Santa Barbara wrote:
> Is there a (de-facto) standard for image metadata/properties?  I'd like
> to be able to able to launch e.g. the Debian Squeeze image provided by
> the cloud.  This is particularly important for clouds that don't allow
> image upload, but likely this will remain useful because different
> clouds will have different tweaks needed (e.g installing the right
> drivers based on the hypervisor).
>
> I could try "smart"-parsing the names, but it seems like metadata is the
> right way to do this, and I see no reason why any cloud would gain any
> advantage from not adopting a common convention.  I know some clouds
> have started implementing their own approaches, but I don't believe
> anyone is locked into anything.
>
> In the interest of efficiency, I'm going to make a proposal for people
> to attack:
>
> 3 main pieces of metadata: os:distro, os:version_major, os:version_minor

In the proposed Images API 2.0, we use JSON Schema's 
additionalProperties collection to allow for discoverable custom 
properties. For the properties you list above, you could either add 
those properties with the prefix you propose above (in 
additionalProperties), or argue for inclusion in the standard 
"properties" collection of the Image Entry schema. You can see both the 
properties and a sample of what additionalProperties are used for shown 
in the schema:

https://docs.google.com/document/d/1rb7ZVn0Du_5NZqUyQpqUZSmv7Qd66TMHYAtvsow7LH4/edit#heading=h.1nk6x0hs4enq

> Questions / ideas for other properties:
>
>   * Some clouds will automatically respin images e.g. weekly with the
>     latest updates.  This could also be exposed through metadata.
>       os:updated_through= "20120301" ?

Possible, though a version identifier would also work. Or simply a query 
like:

GET 
/images/sort_by=created_at&sort_order=desc&limit=1&property-os:distro=Debian

(and you can do that in the existing API as well, BTW)

>   * Some clouds will offer only bare images, some will provide a variety
>     e.g. bare, LAMP, Hadoop, etc.  Should we use the native package
>     names to indicate additional packages?  e.g.
>     os:packages="apache2,mysql,php5" ?

IMHO, no. That would get overkill. In the new API, you could use tags, 
though. Or you could add a custom extension in the new API so that you 
could expose packages as a subresource of /images/<IMAGE_ID>/.

> As a (programmatic) consumer of these images, my wishlist:
>
>   * A cloud will have to put on whatever drivers / agents they need to,
>     but ideally these should otherwise be clean images, with minimal
>     deviation from the stock install.  (Or 'clean' images should be
>     available alongside other images)  It would be great if I could be
>     launch a 'clean' image on any OpenStack cloud and have it behave
>     more or less the same; I shouldn't have to second guess any
>     additional tweaks.

No disagreement from me here, but I don't see how this relates to a 
common set of image properties? Could you elaborate?

>   * I would like to be able to launch the clean image and install
>     updates myself, in case I don't want a particular update.  Providing
>     a fast apt cache is much better than providing respun images, for my
>     use-case.  I would be great if old images stuck around, therefore!

Again, no disagreement, but I'm also confused how this relates to 
standard image properties...

Best,
-jay

> Justin
>
> ---
>
> Justin Santa Barbara
> Founder, FathomDB
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp