Open Stack

On Mar 4, 2014, at 4:09 AM, Sean Dague <sean at 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. :)

- Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140304/191f0f34/attachment.html>