[openstack-dev] [nova] feature branch for Nova v2.1 API?

Daniel P. Berrange berrange at redhat.com
Tue Sep 2 14:18:14 UTC 2014


On Tue, Sep 02, 2014 at 08:54:31AM -0400, Sean Dague wrote:
> I think we finally got to a largely consensus agreement at the mid-cycle
> on the path forward for Nova v2.1 and microversioning. Summary for
> others: Nova v2.1 will be Nova v2 built on the v3 infrastructure (which
> is much cleaner), with json schema based request validation (to further
> clean up and make consistent all the input validation).
> 
> As we hit FF I'm wondering if we consider getting the API conversion a
> high enough priority to run it in parallel during the RC phase of Nova.
> It feels like a ton of other things become easier once we have all this
> working (like actually being able to sanely evolve our API with all the
> new features people show up with), so having that early Kilo would be great.
> 
> One thing we could do is take the v2.1 work into a feature branch during
> the freeze/rc, which would allow getting Tempest functioning on it, and
> get the patch stream ready for early merge in Kilo.
> 
> This has the disadvantage of some portion of the Nova team being focused
> on this during the RC phase, which is generally considered uncool. (I
> agree with that sentiment).
> 
> So it's a trade off. And honestly, I could go either way.
> 
> I'd like to get the feelings of the Nova drivers team on whether getting
> the API on track is deemed important enough to go this approach during
> the Juno RC phase. All opinions welcome.

Do we have any historic precedent of using feature branches in this kind
of way in the past, either in Nova or other projects ? If so, I'd be
interested in how successful it was.

I think it is reasonable to assume that our Juno work is easily capable
of keeping the entire core team 100% busy until Kilo opens. So having
people review v2.1 stuff on a feature branch is definitely going to
impact the work we get done for Juno to some extent, though it is
admittedly hard to quantify this impact in any meaningful way.

Is there a specific compelling reason we need to get it up & reviewed
through gerrit during the gap between juno-3 FF and kilo opening for
business ?  When you refer to getting tempest functioning, are you
talking about actually doing the coding work on tempest to exercise
the new v2.1 API, or are you talking about actually setting up tempest
in the gate systems. If the latter, I can understand why having it up
for review would be a win. If the former, it seems that could be done
regardless of existance of a feature branch.

I don't have a strong opinion since, even if there was a feature branch,
I'd likely ignore it until Kilo opens. If pushed though I'd be just on
the side of making it wait until Kilo opens, just to maximise core team
availability for Juno.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



More information about the OpenStack-dev mailing list