Open Stack

On 03/09/2015 06:04 PM, 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.
>
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150310/73c0516c/attachment.html>