[openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

melanie witt melwittt at gmail.com
Mon Mar 9 22:04:59 UTC 2015


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.

melanie (melwitt)




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150309/85180a9d/attachment.pgp>


More information about the OpenStack-dev mailing list