Open Stack

On 04/09/2012 02:41 PM, Justin Santa Barbara wrote:
> I should probably clarify my terminology a little here, as I may have
> mangled it:
>
>   * I'm talking about additional/extension properties, not properties
>     that are well-known to Glance
>   * However, we agree to use a common set of properties to mean certain
>     things.
>
> In other words, we all agree to call Debian
> "openstack.org:distro=debian.org <http://debian.org>" rather than
> "os_distro=Debian" on Cloud1, "distro=debian.org <http://debian.org>" on
> Cloud2, "name=Debian Squeeze" on Cloud3 etc

Sure.

>         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___5NZqUyQpqUZSmv7Qd66TMHYAtvsow7__LH4/edit#heading=h.__1nk6x0hs4enq
>     <https://docs.google.com/document/d/1rb7ZVn0Du_5NZqUyQpqUZSmv7Qd66TMHYAtvsow7LH4/edit#heading=h.1nk6x0hs4enq>
>
> Ah, OK I understand the proposed  2.0 API a bit better now.
>
> I'd like to solve this now though, not in 6 / 12 / 18 months.  It sounds
> like my proposal is compatible with the new API as well, so no problem
> there!

Yes, I hear you :)

>           * 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)
>
> created_at != updated_through in general.   As a simple example, the
> cloud provider might make a "clean" image (stock Debian 6.0.3) at the
> same time as you make a totally up-to-date image.

You can use updated_at as well in the existing API... though of course, 
it only refers to the image metadata, not the image file itself since 
that is static read-only once uploaded...

> Not sure what you mean by a version identifier?

Debian 6.0.3 is a version identifier...

>           * 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>/.
>
> It is important to differentiate a "minimal" image from a "loaded"
> image, users will typically want a loaded image, code will typically
> want a bare image; alternative suggestions are welcome.  If we're going
> to use tags in 2.0, shouldn't we use properties/metadata today?

Your definition of loaded != others' definition of loaded ;) I'm not 
sure there is going to be a whole lot of success in defining what loaded 
means, though there might be a better success of determining what 
"minimal" means.

Yes, in the existing API, you would use properties. And prefixing those 
properties is perfectly acceptable. Just pointing out we've come up with 
a different solution (tags plus a discoverable schema) in the 2.0 
proposed API.

>         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?
>
> Here's what I see on Cloud X (edited to protect the party, and I removed
> the kernels/ramdisks):
>
> 417 Debian Squeeze 6.0.3 Server 64-bit 20120123            ACTIVE
> x_image_type=machine, image_location=local, image_state=available,
> project_id=None, x_md_version=1, kernel_id=415, min_ram=0,
> ramdisk_id=416, x_image_id=c89dee3bca7a62103f7d88d2a02f4dc8, owner=None,
> x_image_builddate=20120123, architecture=amd64, min_disk=0,
> x_image_version=1x1.1
> 414 CentOS 6.2 Server 64-bit 20120125                      ACTIVE
> x_image_type=machine, image_location=local, image_state=available,
> project_id=None, x_md_version=1, kernel_id=412, min_ram=0,
> ramdisk_id=413, x_image_id=f2fbb1bf37a13e7c5da897c7082684df, owner=None,
> x_image_builddate=20120125, architecture=x86_64, min_disk=0,
> x_image_version=1x1
> 229 Ubuntu Oneiric 11.10 Server 64-bit 20111212            ACTIVE
> image_location=local, image_state=available, kernel_id=228, min_ram=0,
> min_disk=0, architecture=amd64, owner=None, project_id=None
> 227 Ubuntu Natty 11.04 Server 64-bit 20111212              ACTIVE
> image_location=local, image_state=available, kernel_id=226, min_ram=0,
> min_disk=0, architecture=amd64, owner=None, project_id=None
> 225 Ubuntu Maverick 10.10 Server 64-bit 20111212           ACTIVE
> image_location=local, image_state=available, kernel_id=224, min_ram=0,
> min_disk=0, architecture=amd64, owner=None, project_id=None
> 223 Ubuntu Lucid 10.04 LTS Server 64-bit 20111212          ACTIVE
> image_location=local, image_state=available, kernel_id=222, min_ram=0,
> min_disk=0, architecture=amd64, owner=None, project_id=None
> 221 CentOS 5.6 Server 64-bit 20111207                      ACTIVE
> image_location=local, image_state=available, kernel_id=219, min_ram=0,
> ramdisk_id=220, min_disk=0, architecture=x86_64, owner=None,
> project_id=None
> How do I write code to determine:
> Is Debian Squeeze 6.0.4 available?
> Is 6.0.3 is the best I can get?
> Is Debian Wheezy available?
> If there are two Debian 6.0.3 images, one bare and one loaded, how do I
> tell them apart?
> Is CentOS 6.2 a newer version of Debian (supposing I've never heard of
> CentOS, for some reason)?

Gotcha, ok, I understand you better now... and I maintain that in the 
current API, standardizing on property prefixes is perfectly reasonable 
solution, but that in the proposed 2.0 API, you'd use the schema 
document and tags.

>           * 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...
>
> Just a request to bear in mind that some people won't want to run the
> latest image.  Once we agree the metadata we can tell the images apart
> easily (or you can hide them in the GUI), so there's no need to delete
> old images unless there's an SSH exploit.

understood. :)

Best,
-jay