Open Stack

On 03/04/2014 02:03 PM, Chris Behrens wrote:
> 
> On Mar 4, 2014, at 4:09 AM, Sean Dague <sean at dague.net
> <mailto: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. :)

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
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140304/ed92dcd8/attachment.pgp>