Open Stack

Oops, missed this one.

> -----Original Message-----
> From: Brian Waldon [mailto:bcwaldon at gmail.com]
> Sent: Monday, August 27, 2012 6:18 PM
> To: Jay Pipes; Gabe Westmaas
> Cc: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [Glance] Implementing Common Image
> Properties
> 
> Jay, Gabe:
> 
> I don't think we're seeing eye to eye here and I'm starting to question doing
> this at all. I've got some questions that will hopefully help us figure out what
> we really want:
> 
> 1) What are the goals of the OpenStack Images API?

Probably not appropriate to define in an email, but I think it extends beyond a very limited set of properties and image storage location.  Sounds like some BP sessions around really defining what Glance is are in order.

> 
> 2) Should the OpenStack Images API care about image attributes past those it
> absolutely needs to accomplish its goals? For the sake of argument, let's say
> say id, size, checksum are essential while os_distro and os_arch are not.

Depends what the goals are :)  I do think that enabling the ability to programmatically find images that meet certain criteria across multiple clouds, and not requiring that we always know the image ID that each cloud chose.

> 
> 3) Should there exist a suggested usage pattern for properties that aren't
> part of an API specification, whether that be the Images API or something
> new?

Sorry, not sure I know what you mean by this!  You mean "common image properties" for v2?

> 
> 
> Sorry for top-posting.
> 
> Waldon
> 
> 
> 
> On Aug 27, 2012, at 4:13 AM, Jay Pipes wrote:
> 
> > On 08/20/2012 03:17 PM, Gabe Westmaas wrote:
> >> It would definitely be great to see these as generally accepted
> >> properties.  In general, I would hope that anything that is accepted
> >> by the community eventually makes it into core API, and shipping with
> >> them on by default is a great first step.  Mostly, I'd like to see us
> >> able to turn off the "org.openstack__1__" part of the properties, if
> >> everyone agrees they are useful :)
> >
> > ++
> >
> > I wish I'd been a part of that Folsom summit discussion...
> > openstack__1__ is just ugly and once again, I think this is more of a
> > solution in search of a problem as well as Java-esque naming bolted-on
> > to an API spec without a whole lot of practical value.
> >
> > I realize there is a need to have some common image properties, but I
> > will make here three main points:
> >
> > * If they are really common, they should be in the base image
> > attributes
> > -- just like status, created_at, name, etc.
> > * If there is consensus after some version of the API has come out,
> > it's perfectly acceptable to *add* new attributes to the image schema
> > in a minor API version increment. That's what should be done here, IMHO.
> > * Image properties were designed to be custom key/value string pairs
> > that an organization could attach to an image and use internally for
> > their own needs. If that organization was Canonical and wanted to
> > attach a property of "nightly_snapshot_build_revno" to an image, they
> > could do so, and consumers of the image metadata would see that
> > key/value data and use it as they wish. If Rackspace also had some
> > identical key/value property called "nightly_snapshot_build_revno"
> > that they stored some entirely different value in, so be it. The point
> > was that while *disk images themeselves* were supposed to be
> > copy-able/searchable/replicable from one Glance server to another, the
> > metadata that was attached to it was supposed to be specific to the
> > Glance registry server from which that metadata was being retrieved.
> >
> > In short, I'd much rather we adopt a process of proposing:
> >
> > a) Attributes that should be added to a particular v2 Image API schema
> > (or subschema, e.g. image access schema)
> > b) Leave everything else as custom key/value pairs (or even better,
> > tags, which is what I'd originally proposed scrapping k/v pairs for in
> > the v2 API) and don't make any inference that a key/value pair means
> > the same thing across Glance registries (or sets of Glance registries).
> >
> > Here's a sample "form" that would be posted (and voted on at an
> > appropriate meeting) that would solve 99% of these issues IMHO:
> >
> > REQUEST TO ADD ATTRIBUTE TO IMAGE SCHEMA
> > ========================================
> >
> > Proposed Name of Attribute: os_arch
> >
> > JSONSchema of proposed property in Image Schema:
> >
> > {
> > "os_arch":
> > {
> >  "type": "string",
> >  "required": false,
> >  "default": null,
> >  "description": "Operating system architecture",
> >  "enum": ["x86_64","i386","sparc","sparc64", ...] } }
> >
> > Best,
> > -jay
> >
> >> Also just to highlight one of the links in the mailing list
> >> discussions, this is where we pulled those properties
> >> from: http://wiki.openstack.org/CommonImageProperties
> >>
> >> Gabe
> >>
> >> From: Brian Waldon <bcwaldon at gmail.com
> <mailto:bcwaldon at gmail.com>>
> >> Reply-To: OpenStack List <openstack-dev at lists.openstack.org
> >> <mailto:openstack-dev at lists.openstack.org>>
> >> Date: Mon, 20 Aug 2012 14:11:20 -0400
> >> To: "openstack at lists.launchpad.net
> >> <mailto:openstack at lists.launchpad.net>"
> >> <openstack at lists.launchpad.net
> >> <mailto:openstack at lists.launchpad.net>>, OpenStack List
> >> <openstack-dev at lists.openstack.org
> >> <mailto:openstack-dev at lists.openstack.org>>
> >> Subject: [openstack-dev] [Glance] Implementing Common Image
> >> Properties
> >>
> >> We discussed a common set of image properties a while back on the
> >> mailing list ([1] and [2]). The general idea was to define a common
> >> way to expose useful image properties (distro, version, architecture,
> >> packages, etc).
> >>
> >> It doesn't appear we ever came to a hard consensus, but Rackspace has
> >> been publishing the following properties in their deployment:
> >>
> >> org.openstack__1__architecture = x64
> >> org.openstack__1__os_distro = org.ubuntu
> >> org.openstack__1__os_version = 12.04
> >>
> >> If the idea is to get all deployments to publish these properties, I
> >> think what Rackspace has implemented would be a good starting point.
> >> The question I want to pose to the community is this:
> >>
> >> Does it make sense to ship a set of JSON schemas with Glance that
> >> represent these properties? Doing so wouldn't explicitly require all
> >> deployments to use them, but it would reduce the work required to
> >> publish them and help ensure they have a common meaning across
> >> deployments. Keep in mind that we would be shipping these as a part
> >> of Glance, not as a part of the Images API spec.
> >>
> >> I personally think it would be great to provide these, and to do so
> >> in the Folsom release so those deployers riding major releases
> >> wouldn't be left out in the dark.
> >>
> >> All comments welcome!
> >>
> >> Brian Waldon
> >>
> >>
> >> [1] http://markmail.org/message/5bd5zkyre57ppi3n
> >> [2] http://markmail.org/message/soaldxs4lovd2uir
> >> _______________________________________________ OpenStack-
> dev mailing
> >> list OpenStack-dev at lists.openstack.org
> >> <mailto:OpenStack-dev at lists.openstack.org>
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev