Open Stack

First off, sorry for the slow reply. I was on vacation last week.

The project priority list was produced as part of the design summit,
and reflects nova's need to pay down technical debt in order to keep
meeting our users needs. So, whilst driver changes are important, they
doesn't belong on that etherpad.

That said, I think the best way to help us keep up with our code
review requirements is to be an active reviewer. I know we say this a
lot, but many cores optimize for patches which have already been
reviewed and +1'ed by a non-core. So... Code review even with a +1
makes a real difference to us being able to keep up.

If you feel a change has been blocking on review for too long and is
important, then please do raise it in the "Open Discussion" section of
the nova meeting.

Michael

On Sat, Nov 22, 2014 at 2:02 AM, Alessandro Pilotti
<apilotti at cloudbasesolutions.com> wrote:
> 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
>



-- 
Rackspace Australia