Open Stack

On 07/31/2012 02:21 PM, Vishvananda Ishaya wrote:
> The main issue is that we have a bunch of data that we handle as part of a post to servers that is not in the core api spec. This data really belongs to extensions (and is in fact directly related to a specific extension in most cases). Unfortunately, there is no way to turn processing for this extra data off, which is basically a Very Bad Thing™.
> 
> I've been thinking about a simple way to solve this issue, and I've come up with a spec[2] that i think is workable. I'd like to get some decisions on the following at the meeting:
> 
> a) is this approach acceptable?
>  * does it need to be modified slightly?
>  * is renaming the badly named extensions ok?
>  * is there a more general approach that extensions could use?

A few things I think are missing in the discussion:

1) What is the current state of the *published spec, if any*. If we go
about modifying the contours of a published API (no matter how much we
find issues and inconsistencies with it), we really do need to do a
major API version increment IMHO.

2) Given that we do actually clean up the request extension data, how do
we prevent (in either a human or systemic way) this from happening in
the future?

3) I think the instance-type-extra-data extension is missing from the
list of extensions that may modify POST/request data

4) Do we have a plan on when extensions move from an extension into a
part of the core Compute API?

5) Do we have a plan for how to delete an extension that doesn't "work out"?

> b) is there an alternative to this that is easier/better?
>  * alternative: bump minor version of the api?

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.

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?

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.

Best,
-jay