Open Stack

Sorry for the delay in responding all. Comments inline.

On Mon, Mar 09, 2015 at 03:04:59PM -0700, melanie witt wrote:
> On Mar 9, 2015, at 13:14, Sean Dague <sean at dague.net> wrote:
> > So possibly another way to think about this is our prior signaling of
> > what was supported by Nova was signaled by the extension list. Our code
> > was refactored into a way that supported optional loading by that unit.
> > 
> > As we're making things less optional it probably makes sense to evolve
> > the API code tree to look more like our REST resource tree. Yes, that
> > means servers.py ends up being big, but it is less confusing that all
> > servers related code is in that file vs all over a bunch of other files.
> > 
> > So I'd agree that in this case server tags probably should just be in
> > servers.py. I also think long term we should do some "plugin collapse"
> > for stuff that's all really just features on one resource tree so that
> > the local filesystem code structure looks a bit more like the REST url tree.
> 
> I think this makes a lot of sense. When I read the question, "why is
> server tags being added as an extension" the answer that comes to mind
> first is, "because the extension framework is there and that's how
> things have been done so far."
> 
> I think the original thinking on extensions was, make everything
> optional so users can enable/disable as they please, operators can
> disable any feature by removing the extension. Another benefit is the
> ability for anyone to add a (non-useful to the community at-large)
> feature without having to patch in several places.
> 
> I used to be for extensions for the aforementioned benefits, but now I
> tend to think it's too flexible and complex. It's so flexible that you
> can easily get yourself into a situation where your deployment can't
> work with other useful tools/libraries/etc which expect a certain
> contract from the Nova API. It doesn't make sense to let the API we
> provide be so arbitrary. It's certainly not friendly to API users.

Right. This is the number one reason API extensions need to go bye bye.

> We still have the ability to disable or limit features based on policy
> -- I don't think we need to do it via extensions.

Agreed.

> The only problem that seems to be left is, how can we allow people to
> add un-upstreamable features to the API in their internal deployments?
> I know the ideal answer is "don't do that" but the reality is some
> things will never be agreed upon upstream and I do see value in the
> extension framework for that. I don't think anything in-tree should be
> implemented as extensions, though.

IMO, all of the above functionality belongs as an entirely different
endpoint and REST API.

If it's not in the Nova /nova/api/ directory, it's not the Nova API.

As I've written a number of times before, just because achieving some
modicum of consensus about some new API resource or feature is hard,
does not mean that we should spend our time enabling vendors and others
to circumvent the API writing process by using API extensions.

It's hard work coming to consensus about a new API feature. But it's
necessary work.

Best,
-jay