On Mon, 3 Mar 2014 22:14:02 -0800 Chris Behrens <cbehr...@codestud.com> 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.
So at the moment we have this conflict between getting new api features in NOW and having to balance that with the pain of having to support any mistakes forever. Especially at this stage of cycle I feel really bad about -1'ing API code because it might mean that they have to wait another cycle and often the API code is just the tip of a really big chunk of work. But at the same time once we merge these API features we have to live with them forever. So there's been the odd discussion going on about how we raise the bar for making API changes, and I think what you have suggested would fit in really well. It would allow us to continue to innovate quickly, but extensions outside of nova could been seen as experimental and potentially subject to backwards incompatible API changes so we're not stuck with mistakes indefinitely. > 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’? So the good news is that the V3 API framework already supports this sort of model really well. Under the hood it is based on hooks and allowing different parts of the API to offer hook points for other parts of the API to extend. It's one of the techniques we used to clean up the mess that is the V2 API servers code which is "core" but littered with extension specific code. Separating it all logically makes it much easier to read/maintain. There's also some nice extra controls so you can if you wish through whitelist/blacklists ensure that the environment doesn't start loading new API features unexpectedly and complains loudly when ones you think should be there aren't. > 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 for want of a better term, "incubating potential" API features for a cycle or two before graduating them into the Nova tree would I think be very valuable. It avoids where its hard to really use the API until its implemented, but you learn a lot from using it but by then its too late. It allows us to have graduation type criteria like - "is anyone using it?", "is all of the interface used, or only part of it", "how does this fit into the overall Nova API", etc. We can also fix all the various little bugs in the API design before it gets locked in. And we'll avoid situations like quota_classes which got merged and shipped for a while but as far as we can tell never really did anything useful because the rest of it didn't get finished. So a big +1 from me for this. But I think we'd want to be able to symmetrically gate on this code, otherwise it becomes a bit of nightmare for people maintaining code in this external repository. Chris _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
