On Mar 3, 2014, at 9:23 PM, Joe Gordon <joe.gord...@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. - Chris _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
