openstack team mailing list archive

[Nathanael Burton <nathanael.i.burton@xxxxxxxxx>]

Better yet why not add support in Glance for automatically determining
those things (distro, versions, etc)[1]. That way you don't have to rely on
people doing the right thing.

Nate

References:

[1] -
http://libguestfs.org/virt-inspector.1.html#getting_inspection_data_from_the_libguestfs_api
On Apr 7, 2012 8:19 PM, "Justin Santa Barbara" <justin@xxxxxxxxxxxx> wrote:

> I'm talking here about publicly accessible attributes of images, that the
> image owner would set, so that API callers could select the right image
> with which to launch their instances.
>
> e.g. I'm trying to launch a Zookeeper cluster made up of 5 instances on 5
> different clouds; how can I figure out which image is "Debian Squeeze" on
> each of AT&T, Rackspace, HP, IBM, Internap, Dreamhost etc.  I could code
> image ids or logic for each of the clouds, but that's already annoying with
> a handful of clouds and impractical with 100.  Now imagine also that the
> images are being re-spun each week!
>
> There's no protection against the image uploader setting the wrong values,
> so the API user would definitely only want images from trusted providers.
>  Is there an easy way to differentiate publicly shared images from
> 'official' cloud images?
>
> I don't believe these attributes would be suitable for billing purposes.
>  You could make it so that certain attributes can't be changed by the user
> (e.g. billing codes), or that some values are system assigned (e.g. "this
> is an official image"), but I think that's a future conversation / future
> Glance feature.
>
> I'm just thinking this set of attributes would be a win for everyone vs.
> each cloud rolling their own, so we can just agree them without any need
> for code!
>
> Justin
>
>
> On Sat, Apr 7, 2012 at 3:43 PM, Jamey Meredith <
> jamey.meredith@xxxxxxxxxxxxx> wrote:
>
>>  So would these accessible via a system admin API only?   The problem we
>> face as a
>> Public cloud is that we need to know things about an image for billing
>> purposes.   If a user can snapshot one of my windows images and change the
>> distro field to Debian to avoid license fees, that wont work for us.  I
>> need to know the distro that this image was originally based upon.
>>
>>  I also need to denote things like managed service level for an image
>> that might be the same base distro as an unmanaged image.
>>
>> Sent from my iPhone
>>
>> On Apr 7, 2012, at 5:14 PM, "Justin Santa Barbara" <justin@xxxxxxxxxxxx>
>> 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,
>> ubuntu.com, debian.org, centos.org etc
>>
>> os:version_major would be the major version of the release:
>> debian.org: 6.0, 5.0, 4.0, 3.1, 3.0, 2.2, 2.1, 2.0
>> 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" 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!
>>
>>
>>  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
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>