On 03/09/2015 06:04 PM, melanie witt wrote:
On Mar 9, 2015, at 13:14, Sean Dague <s...@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.
We still have the ability to disable or limit features based on policy -- I
don't think we need to do it via extensions.
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.
At the moment this is provided for by an experimental flag in the
response headers:
https://git.openstack.org/cgit/openstack/nova-specs/tree/specs/kilo/approved/api-microversions.rst#n182
. It is intended to be used for transitioning from the current state of
extensions to a place where optional API extensions aren't allowed, but
that discussion can continue if there's a case for allowing some
optional components for deployers. I'm in favor of having a mechanism
for adding features to an deployment as long as it's exposed in a way
that makes it clear that it's separate from the standard API, e.g. an
entirely separate tree, not just resource prefixes.
melanie (melwitt)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
