I should probably clarify my terminology a little here, as I may have mangled it:<div><ul><li>I'm talking about additional/extension properties, not properties that are well-known to Glance</li><li>However, we agree to use a common set of properties to mean certain things.</li>
</ul></div><div>In other words, we all agree to call Debian "openstack.org:distro=<a href="http://debian.org">debian.org</a>" rather than "os_distro=Debian" on Cloud1, "distro=<a href="http://debian.org">debian.org</a>" on Cloud2, "name=Debian Squeeze" on Cloud3 etc</div>
<div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3 main pieces of metadata: os:distro, os:version_major, os:version_minor<br>
</blockquote>
<br></div>
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:<br>
<br>
<a href="https://docs.google.com/document/d/1rb7ZVn0Du_5NZqUyQpqUZSmv7Qd66TMHYAtvsow7LH4/edit#heading=h.1nk6x0hs4enq" target="_blank">https://docs.google.com/<u></u>document/d/1rb7ZVn0Du_<u></u>5NZqUyQpqUZSmv7Qd66TMHYAtvsow7<u></u>LH4/edit#heading=h.<u></u>1nk6x0hs4enq</a></blockquote>
<div><br></div><div>Ah, OK I understand the proposed 2.0 API a bit better now.</div><div><br></div><div>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!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * Some clouds will automatically respin images e.g. weekly with the<div class="im">
latest updates. This could also be exposed through metadata.<br>
os:updated_through= "20120301" ?<br>
</div></blockquote>
<br>
Possible, though a version identifier would also work. Or simply a query like:<br>
GET /images/sort_by=created_at&<u></u>sort_order=desc&limit=1&<u></u>property-os:distro=Debian<br>
(and you can do that in the existing API as well, BTW)<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Not sure what you mean by a version identifier?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Some clouds will offer only bare images, some will provide a variety<div class="im">
e.g. bare, LAMP, Hadoop, etc. Should we use the native package<br>
names to indicate additional packages? e.g.<br>
os:packages="apache2,mysql,<u></u>php5" ?<br>
</div></blockquote>
<br>
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>/.<br></blockquote>
<div><br></div><div>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?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
As a (programmatic) consumer of these images, my wishlist:<br>
<br></div>
* A cloud will have to put on whatever drivers / agents they need to,<div class="im">
but ideally these should otherwise be clean images, with minimal<br>
deviation from the stock install. (Or 'clean' images should be<br>
available alongside other images) It would be great if I could be<br>
launch a 'clean' image on any OpenStack cloud and have it behave<br>
more or less the same; I shouldn't have to second guess any<br>
additional tweaks.<br>
</div></blockquote>
<br>
No disagreement from me here, but I don't see how this relates to a common set of image properties? Could you elaborate?<br></blockquote><div><br></div><div>Here's what I see on Cloud X (edited to protect the party, and I removed the kernels/ramdisks):</div>
<div><br></div><div>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 </div>
<div>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 </div>
<div>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 </div>
<div>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 </div>
<div>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 </div>
<div>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 </div>
<div>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 </div>
<div> </div><div>How do I write code to determine:</div><div>Is Debian Squeeze 6.0.4 available?</div><div>Is 6.0.3 is the best I can get?</div><div>Is Debian Wheezy available?</div><div>If there are two Debian 6.0.3 images, one bare and one loaded, how do I tell them apart?</div>
<div>Is CentOS 6.2 a newer version of Debian (supposing I've never heard of CentOS, for some reason)?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* I would like to be able to launch the clean image and install<div class="im">
updates myself, in case I don't want a particular update. Providing<br>
a fast apt cache is much better than providing respun images, for my<br>
use-case. I would be great if old images stuck around, therefore!<br>
</div></blockquote>
<br>
Again, no disagreement, but I'm also confused how this relates to standard image properties...<br></blockquote><div><br></div><div>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.</div>
<div><br></div></div></div>