[openstack-dev] [nova] Team meeting details

Jay Pipes jaypipes at gmail.com
Wed Aug 1 15:46:11 UTC 2012


On 08/01/2012 10:42 AM, Kevin L. Mitchell wrote:
> On Wed, 2012-08-01 at 01:33 -0400, Jay Pipes wrote:
>> Yeah. A few things pop to mind:
>>
>> 1) I think extensions should have a version all their own. Right now,
>> there is no versioning of an extension's REST API and therefore there is
>> no safeguard in place to prevent backwards-incompatible API changes in
>> an extension.
> 
> They do.  Extensions have an "updated" class attribute which contains a
> date and time in ISO-8601 format.  That is, admittedly, clunky, and I
> personally would prefer a number or dotted-number version format.

Yeah, clunky. Versions would be better.

>> 2) Get rid of the os: prefix. It's silly and confusing. It can be
>> misinterpreted to mean "operating system" and if it means "OpenStack",
>> then its redundant -- what descriptive value does it denote?
> 
> Well, it's meant to differentiate extensions that are possible future
> first-class elements of the API from vendor-specific elements.  Would
> you prefer "osapi"?

No, I'd prefer to get rid of the os: prefix entirely. Things without a
vendor prefix should be assumed to be "possiuble for future inclusion
into the core API"

>> 3) Get rid of the concept of "admin extensions". An extension is an
>> extension. Whether or not it is an administrative action is entirely up
>> to the deployer and what they set in the policy.json files.
> 
> Actually, the situation is already exactly as you describe here: an
> "admin extension" is merely an extension with policy configured to allow
> access to admins.  We seem to be using the term "admin extension" merely
> to convey to users that a particular extension is intended for
> administrators.

Yes, I know that is the case. I'm referring to people writing "this is
an admin extension" or referring to extensions in documentation as
"admin extensions"...

Best,
-jay



More information about the OpenStack-dev mailing list