On 03/04/2014 02:03 PM, Chris Behrens wrote: > > On Mar 4, 2014, at 4:09 AM, Sean Dague <s...@dague.net > <mailto:s...@dague.net>> wrote: > >> On 03/04/2014 01:14 AM, Chris Behrens wrote: >>> […] >>> I don’t think I have an answer, but I’m going to throw out some of my >>> random thoughts about extensions in general. They might influence a >>> longer term decision. But I’m also curious if I’m the only one that >>> feels this way: >>> >>> I tend to feel like extensions should start outside of nova and any >>> other code needed to support the extension should be implemented by >>> using hooks in nova. The modules implementing the hook code should be >>> shipped with the extension. If hooks don’t exist where needed, they >>> should be created in trunk. I like hooks. Of course, there’s probably >>> such a thing as too many hooks, so… hmm… :) Anyway, this addresses >>> another annoyance of mine whereby code for extensions is mixed in all >>> over the place. Is it really an extension if all of the supporting >>> code is in ‘core nova’? >>> >>> That said, I then think that the only extensions shipped with nova >>> are really ones we deem “optional core API components”. “optional” >>> and “core” are probably oxymorons in this context, but I’m just going >>> to go with it. There would be some sort of process by which we let >>> extensions “graduate” into nova. >>> >>> Like I said, this is not really an answer. But if we had such a >>> model, I wonder if it turns “deprecating extensions” into something >>> more like “deprecating part of the API”… something less likely to >>> happen. Extensions that aren’t used would more likely just never >>> graduate into nova. >> >> So this approach actually really concerns me, because what it says is >> that we should be optimizing Nova for out of tree changes to the API >> which are vendor specific. Which I think is completely the wrong >> direction. Because in that world you'll never be able to move between >> Nova installations. What's worse is you'll get multiple people >> implementing the same feature out of tree, slightly differently. > > Right. And I have an internal conflict because I also tend to agree with > what you’re saying. :) But I think that if we have API extensions at > all, we have your issue of “never being able to move”. Well, maybe not > “never”, because at least they’d be easy to “turn on” if they are in > nova. But I think for the random API extension that only 1 person ever > wants to enable, there’s your same problem. This is somewhat off-topic, > but I just don’t want a ton of bloat in nova for something few people use. > >> >> I 100% agree the current extensions approach is problematic. It's used >> as a way to circumvent the idea of a stable API (mostly with "oh, it's >> an extension, we need this feature right now, and it's not part of core >> so we don't need to give the same guaruntees.") > > Yeah, totally.. that’s bad. > >> >> So realistically I want to march us towards a place where we stop doing >> that. Nova out of the box should have all the knobs that anyone needs to >> build these kinds of features on top of. If not, we should fix that. It >> shouldn't be optional. > > Agree, although I’m not sure if I’m reading this correctly as it sounds > like you want the knobs that you said above concern you. I want some > sort of balance. There’s extensions I think absolutely should be part of > nova as optional features… but I don’t want everything. :)
I want to give the knobs to the users. If we thought it was important
enough to review and test in Nova, then we made a judgement call that
people should have access to it.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
