Open Stack

Thanks Padraig & Nathanael - virt-inspector is a great source of
inspiration.  Can we put the virt-inspector output into a glance property?
 Would all the clouds agree to do that?

I still would also like simpler metadata, as it just feels like too much
information and work required for what is a comparatively simple use case
("launch the official Debian Squeeze image" either "the latest one" or "a
known revision").

Most importantly, I would like to see a solution to this now, rather than
with the next release... If we agree these attributes now, we won't have to
solve the unification problem in 6 months.

Padraig: Can you explain the issue with "updated_through"?  I would have
thought that would define a unique set of package versions (if I'm using
the standard repos)?  I expect that most people will either want to pick
the oldest image (with a particular minor vision) or the newest image (with
the greatest minor version), so it might be that this simply doesn't matter
other than to define an ordering.  It might also be that the creation date
is adequate here.

I have no objection to whatever attributes we define today being populated
automatically using these cool tools in future!

Justin



2012/4/7 Nathanael Burton <nathanael.i.burton at gmail.com>

> Looks like Pádraig and I were thinking alike.
> On Apr 7, 2012 8:49 PM, "Pádraig Brady" <P at draigbrady.com> wrote:
>
>> On 04/07/2012 11: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
>> >
>> > I'm thinking of the os prefix as standing for OpenStack, not Operating
>> System.  I'd like to 'reserve' the os prefix for 'agreed' prefixes.  Maybe
>> this should be openstack.org:distro ?
>> >
>> > os:distro would be the primary domain name of the distro, i.e.
>> redhat.com <http://redhat.com>, ubuntu.com <http://ubuntu.com>,
>> debian.org <http://debian.org>, centos.org <http://centos.org> etc
>> >
>> > os:version_major would be the major version of the release:
>> > debian.org <http://debian.org>: 6.0, 5.0, 4.0, 3.1, 3.0, 2.2, 2.1, 2.0
>> > ubuntu.com <http://ubuntu.com>: 10.04, 10.10, 11.04, 11.10, 12.04
>> >
>> > Numbers seem more machine-friendly than codenames - 6.0, not squeeze -
>> humans will probably use the image names.
>> >
>> > 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).
>> >
>> > So os:distro="debian.org <http://debian.org>" os:version_major "6.0"
>> os:version_minor "3" would be an image of debian 6.0.3.
>> >
>> > 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" ?
>> >   * 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" ?
>> >
>> > 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.
>> >   * 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!
>> >
>>
>> This overlaps a lot with the output from the virt-inspector component of
>> libguestfs,
>> which might help solidify ideas:
>>
>> $ virt-inspector /var/lib/libvirt/images/rh63.img
>>
>> <operatingsystems>
>>  <operatingsystem>
>>    <root>/dev/VolGroup/lv_root</root>
>>    <name>linux</name>
>>    <arch>x86_64</arch>
>>    <distro>rhel</distro>
>>    <product_name>Red Hat Enterprise Linux Workstation release 6.3 Beta
>> (Santiago)</product_name>
>>    <major_version>6</major_version>
>>    <minor_version>3</minor_version>
>>    <package_format>rpm</package_format>
>>    <package_management>yum</package_management>
>>    <hostname>localhost.localdomain</hostname>
>>    <format>installed</format>
>>    ...
>>    <applications>
>>      ...
>>      <application>
>>        <name>coreutils</name>
>>        <version>8.4</version>
>>        <release>18</release>
>>      </application>
>>      ...
>>
>> Note that it doesn't have an "updated_through" element, but that would be
>> fairly
>> amorphous anyway given the combinations possible through updates.
>>
>> cheers,
>> Pádraig.
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120407/eeca12c9/attachment.html>