openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

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
>
>