Open Stack

Hi,

Not seeing any driver (Hyper-V, VMWare, etc) related priority in this etherpad
worries me a bit.


My concern is mostly related to the fact that we have in Nova a significative
number of driver related blueprints code already under review for Kilo and we
are already drifting into the old familiar “Nova rebase hell” at the very
beginning of the cycle. :-)

The Nova core team is obviously doing everything possible to make everybody
happy, I surely have no complains in the amount of effort put into the
reviewing machine, but the total effort required seems simply hopelessly
overwhelming for a single centralized team and lower priority features / bugs
will suffer. 

Looking at the pending reviews count, a significative non trivial amount of the
patches is related to the drivers (see stats below) but since driver blueprints
and bugs are very rarely prioritized, I suspect that we might end up with
another upstream release with inadeguate support for most hypervisors beside
the “blessed” libvirt / KVM, resulting in a lot of blueprints and bug fixes
postponed to the next release.

The last discussion on this ML [1] on splitting the divers from Nova had a lot
of consensus, no more than two months ago. I wonder why wasn’t this discussed
further, for example at the design summit?

In Hyper-V we averted this crisis by simply focusing on the downstream stable
branches (e.g. [2] for Juno), where we reached the quality, stability and
feature levels that we wanted [3], leaving the upstream driver code as a simple
“take it or leave it” best effort code that we surely don’t advise any of our
users to even bother with. Every single line of code that we produce and merge
downstream is obviously also sent upstream for review and eventually merged
there as well, but we don’t necessarily worry anymore about the fact that it
takes months for this to happen, even if we still put a lot of effort into it.

At this stage, since the drivers are a completely partitioned and independent
subset of Nova, the real umbilical cord that prevents a driver maintainer team
to simply leave the Nova project and continue on StackForge is the third party
CI system support, which with all its limitations it's still an amazing
achievement. 
In particular third party CIs are extremely important from a hypervisor
perspective to make sure that Nova changes don't cause regressions in the
drivers (more than the other way around). This means that realistically, for a
driver, leaving Nova and even going back through the Stackforge purgatory is
simply not an option, unless there is a highly unrealistical consensus in still
mantaining a voting CI in Nova for what would become an external driver
resulting from a schism.

Please consider this just as a constructive discussion for the greater good of
the whole OpenStack community [4] :-)

Thanks,

Alessandro


Quick stats showing open reviews (please forgive the simplifications):

All Nova (master):      657

All nova/virt:          208

nova/virt/hyperv:       31
nova/virt/libvirt:      80
nova/virt/vmwareapi:    63
nova/virt/xenapi:       28

Values have been obtained with the following very basic query, not considering
overlapping patches, unit tests, etc:

gerrymander changes -p openstack/nova $PATH --status open --branch master -m json \ 
python -c "import sys; import json; print len(json.load(sys.stdin)[0]['table']['content'])"


[1] Last Nova drivers split discussion: http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html
[2] Stable Hyper-V downstream Juno branch: https://github.com/cloudbase/nova/tree/2014.1.2-cloudbase-release
[3] Extensive downstream Hyper-V Tempest tests: http://www.cloudbase.it/openstack-on-hyper-v-release-testing/
[4] http://whatsthepont.files.wordpress.com/2012/02/20120212-223344.jpg




> On 20 Nov 2014, at 11:17, Michael Still <mikal at stillhq.com> wrote:
> 
> Hi,
> 
> as discussed at the summit, we want to do a better job of tracking the
> progress of work on our priorities for Kilo. To that end, we have
> agreed to discuss the current state of these at each nova meeting.
> 
> I have created this etherpad:
> 
>   https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
> 
> If you are the owner of a priority, please ensure it lists the reviews
> you currently require before the meeting tomorrow. If you could limit
> your entry to less than five reviews, that would be good.
> 
> Thanks,
> Michael
> 
> -- 
> Rackspace Australia
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev