<br><br><div class="gmail_quote">On Sat, Apr 7, 2012 at 6:13 PM, Justin Santa Barbara <span dir="ltr"><<a href="mailto:justin@fathomdb.com">justin@fathomdb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<div>
<br></div><div>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.<br>
<br>In the interest of efficiency, I'm going to make a proposal for people to attack:<br><br>3 main pieces of metadata: os:distro, os:version_major, os:version_minor<br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>I'm thinking of the os prefix as standing for OpenStack, not Operating System. </div></blockquote><div><br></div><div>I would never have guessed that from the context. Why OpenStack instead of Operating System?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> I'd like to 'reserve' the os prefix for 'agreed' prefixes. Maybe this should be openstack.org:distro ? </div>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>os:distro would be the primary domain name of the distro, i.e. <a href="http://redhat.com" target="_blank">redhat.com</a>, <a href="http://ubuntu.com" target="_blank">ubuntu.com</a>, <a href="http://debian.org" target="_blank">debian.org</a>, <a href="http://centos.org" target="_blank">centos.org</a> etc<br>
<br>os:version_major would be the major version of the release:<br><a href="http://debian.org" target="_blank">debian.org</a>: 6.0, 5.0, 4.0, 3.1, 3.0, 2.2, 2.1, 2.0<br><a href="http://ubuntu.com" target="_blank">ubuntu.com</a>: 10.04, 10.10, 11.04, 11.10, 12.04<br>
<br>Numbers seem more machine-friendly than codenames - 6.0, not squeeze - humans will probably use the image names.<br></div></blockquote><div><br></div><div>Are the major and minor numbers going to be sufficient versioning information? See for example PEP 386 for more detailed version strings (<a href="http://www.python.org/dev/peps/pep-0386/">http://www.python.org/dev/peps/pep-0386/</a>).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>os:version_minor would be the minor version of the release (because it's a minor revision, hopefully we shouldn't normally have to check this, although we might want to select the latest always).<br>
<br>So os:distro="<a href="http://debian.org" target="_blank">debian.org</a>" os:version_major "6.0" os:version_minor "3" would be an image of debian 6.0.3.<br><br>Questions / ideas for other properties:<div>
<ul><li>Some clouds will automatically respin images e.g. weekly with the latest updates. This could also be exposed through metadata. os:updated_through= "20120301" ? </li><li>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" ?</li>
</ul></div></div></blockquote><div>The package names may vary depending on the platform, so the names probably shouldn't be tied to the names of the packages themselves but to the projects. Or maybe that's just a taxonomy problem that should be left up to the taggers.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><ul>
</ul></div><div>As a (programmatic) consumer of these images, my wishlist:<br><ul><li>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.</li>
<li>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!</li>
</ul><div><br></div>Justin<br><br>---<br><br>Justin Santa Barbara<br>Founder, FathomDB<br><br><br></div></div>
<br>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></blockquote></div><br>