Open Stack

On Mon, 3 Mar 2014 22:14:02 -0800
Chris Behrens <cbehrens at 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