Open Stack

On Tue, 2014-01-14 at 11:45 +0800, Christopher Yeoh wrote:
> On Tue, Jan 14, 2014 at 10:59 AM, Jay Pipes <jaypipes at gmail.com>
> wrote:
>         
>         We don't need API extensions and they make our Compute API
>         laughably complex and cumbersome. We should ditch entirely the
>         concept of API extensions in our next Compute API major
>         release.
> 
> I think it way too late in the cycle to make this sort of change for
> the V3 API.

Completely agreed. I never said anything about v3. Specifically, in the
tl;dr section I said "in the next major API version" we should get rid
of API extensions.

>         
>         admin_actions -- seriously...why wouldn't pause/unpause, etc
>         be part of
>         the API? if some hypervisor doesn't support the action, then
>         raise
>         NotImplemented and return an HTTP 501 Not Implemented -- after
>         all,
>         that's what a 501 was designed for, and client tooling for
>         HTTP APIs
>         should understand that.
> 
> 
> So interestingly the feedback we got at the HK design summit session
> around admin_actions
> is that we should split it up into multiple smaller extensions (and
> this is going through
> now). So deployers could more selectively deploy what they want to and
> not include what
> they don't want.

If it wasn't clear, I was not proposing changing anything to do with the
existing v3 API or any of the extensions. I am saying we should get rid
of them for the next major version, which would be v4.

BTW, I challenge you to find deployers that are clamouring for the
ability to "selectively deploy" some parts of the API and not
others...I'd be happy to have conversations with these people and figure
out what the real use cases are and what they're really after -- because
I can almost guarantee it's not yet more API extensions.

> > And although we don't really have an official policy around it, I
> > think the API extension functionality has been used as a way of
> > allowing new functionality into Nova and evaluating it in place
> before
> > deciding whether or not it becomes a core part of Nova.
> 
> 
>         I do understand this. But, I just think that it's mainly
>         laziness that
>         drives this. Instead of doing the hard work of determining a
>         useful API
>         structure ahead of time -- and validating that the new
>         features actually
>         fit the API audience -- it's just one more way of pushing
>         immature or
>         ill-fitting code into a codebase.
>         
>         Sorry for ranting.
> 
> 
> Ranting is fine with me :-) But if its something we wanted to do for
> the V3 API we really should
> 
> have had this sort of discussion at the *Havana* design summit.

I've brought up the problems before with API extensions numerous times,
but unfortunately, I haven't voiced enough concern over the last 18
months or so, being lost a bit in ops-land. That said, I plan to
vigorously argue for scrapping all API extensions in v4 at the Juno
summit. This practice has just gone on way too long...

> FWIW I think we're getting a lot better at doing quality control on
> APIs which are added.

No disagreement.

Best,
-jay