Open Stack

On 03/04/2014 01:14 AM, Chris Behrens wrote:
> 
> On Mar 3, 2014, at 9:23 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> 
>> Hi All,
>>
>> here's a case worth exploring in a v2 only world ... what about some
>> extension we really think is dead and should go away?  can we ever
>> remove it? In the past we have said backwards compatibility means no
>> we cannot remove any extensions, if we adopt the v2 only notion of
>> backwards compatibility is this still true?
> 
> 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.

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.")

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.

If that means we need to have more folks spending time on coming
together on that interface, so be it, but this world where Nova is a
bucket of parts isn't pro-user.

A really great instance is the events extension that Dan is working on.
Without it, Neutron can't work reliably. But it's an extension. So you
can turn it off. So we just made it optional to work with the rest of
OpenStack. Also the fact that it was an admin API was used as
justification on that. But if reliable integration with Neutron isn't
considered a core feature of Nova... well, I'm not sure what would be.

	-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/06cdd8ce/attachment.pgp>