I would also like to have a discussion about the following:

org.openstack__1__default_fs  = ext4 : default filesystem to use, for example, 
for ephemeral storage
org.openstack__1__root_partition = 2 : Partition number of the root partition, 
used for key and file injection (0 for an unpartitioned image)
org.openstack__1__provider = com.hp : Entity that provided/built the image

I understand that Folsom is smart and can automatically determine the root 
partition so maybe root_partition is not really that useful but it would be 
simple and easy and wouldn't require to inspect the image. Similarly, with 
image inspection, the root filessystem could be determined automatically and 
ephemeral could be formatted using the same filesystem but I'm not sure if 
image inspection is supported on all platforms.

...Juerg



From: [email protected] 
[mailto:[email protected]] On Behalf 
Of Hancock, Tom (HP Cloud Services)
Sent: Tuesday, August 28, 2012 5:58 PM
To: OpenStack List; [email protected]
Subject: Re: [Openstack] [openstack-dev] [Glance] Implementing Common Image 
Properties

Yes we'd love to see these included also.
: Tom

From: [email protected] 
[mailto:[email protected]] On Behalf Of 
Gabe Westmaas
Sent: 20 August 2012 20:18
To: OpenStack List; [email protected]
Subject: Re: [Openstack] [openstack-dev] [Glance] Implementing Common Image 
Properties

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

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 <[email protected]<mailto:[email protected]>>
Reply-To: OpenStack List 
<[email protected]<mailto:[email protected]>>
Date: Mon, 20 Aug 2012 14:11:20 -0400
To: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>, 
OpenStack List 
<[email protected]<mailto:[email protected]>>
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 
[email protected]<mailto:[email protected]> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to