[openstack-dev] [Glance] Implementing Common Image Properties

Brian Waldon bcwaldon at gmail.com
Mon Aug 27 22:18:08 UTC 2012


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?

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.

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




More information about the OpenStack-dev mailing list