Open Stack

Armando M. <armamig at gmail.com> wrote:

> Neutrinos,
>
> We have about ~20 outstanding bugs marked Medium/High/Critical, and we  
> have only one or two days left to have a chance to get them in the gate  
> queue [1]. Can I trouble you to go and make sure patches are up to date  
> and well reviewed?
>
> Many thanks,
> Armando
>
> [1] https://launchpad.net/neutron/+milestone/mitaka-rc1

Hi Armando and all,

[Full disclosure: I am really interested in getting stable/mitaka cut off  
asap due to the code sprint starting on Mon where we would like to land a  
number of N bits to master.]

Currently I see 25 unreleased bugs targeted for RC1. I believe the list is  
too broad and does not represent actual team priorities as of right now; I  
suggest we go thru the list and postpone those bugs that either won’t land  
on Mon, or aren't really critical for the release; then cut-off  
stable/mitaka to unblock master.

If you think the list is fine, remember that at this point we should land  
only safe fixes, or those that make release impossible [aka ‘something base  
to the cloud operation is totally broken in Mitaka comparing to Liberty’].  
If you like, you can compare Neutron with its 25 targeted bugs to other  
projects (hint: nova - 2 bugs; glance - 2 bugs; cinder - 5 bugs; horizon -  
12 bugs). If we would start landing all cool stuff that we happen to  
produce in the last week, we would be undermining freeze and release  
process, also raising chances of releasing a pile of broken code.

With that in mind, I went through the target to see what is really critical  
for the release.

===

We have 18 bugs that are High+. Below is each of those bugs, with [*] mark  
where I think RC target is justified at this point.

https://bugs.launchpad.net/neutron/+bug/1523031: linuxbridge + l2pop + l3ha  
broken.
^ while it’s unfortunate, I don’t see how it stands for a release critical  
bug since it affects setup that is not really that common. Also, looking at  
the bug state, I don’t see any work started on it. I would prefer we drop  
it out of RC1 target.

https://bugs.launchpad.net/bugs/1551288
^ fullstack (non-voting) job sometimes fails for native ovsdb interface. No  
idea why it’s critical for the release. Suggesting to postpone to N.

https://bugs.launchpad.net/bugs/1513765 [*]
^ conntrack calls block ovs agent; patch in review optimizes for some use  
cases, but does not tackle the general issue of the agent being blocked;  
patch opens some rolling upgrade scenario concerns too since it touches RPC  
version and method signatures; that said, we indeed want to try to tackle  
it in RC;

https://bugs.launchpad.net/neutron/+bug/1556139 [*]
^ create/delete race when returning new resource body in ml2; the patch is  
up for review and ready for merge; good to go;

https://bugs.launchpad.net/neutron/+bug/1453350
^ port ready event sent to nova before dhcp is ready; not a regression: was  
always the case; the proper fix would require a lot of work; definitely  
won’t happen in Mitaka; I believe should be dropped from RC target;

https://bugs.launchpad.net/neutron/+bug/1456073 [*]
^ dvr not ready yet when live migration triggered; targeted for RC on both  
nova and neutron sides; neutron patch in review, has needed +2s; good to go;

https://bugs.launchpad.net/neutron/+bug/1462154
^ dvr returns fip targeted pings with fixed ips; patch up for review [WIP];  
not sure whether it will make it; I suggest we don’t wait for that one;

https://bugs.launchpad.net/bugs/1478100
^ physical network aware dhcp scheduler; honestly, that one is rather  
feature-ish; I would untarget it from Mitaka on that ground;

https://bugs.launchpad.net/bugs/1491131
^ ipset race; this one seems abandoned right now; no patches for review;  
long standing issue; I would move it to N;

https://bugs.launchpad.net/neutron/+bug/1498790
^ allow to delete other’s ports from your network; while obviously a bug,  
the fix could be also considered rather feature-ish, since it change API  
behaviour; there seems to be no active patches in gerrit for that; I would  
postpone it till N when we’ll have more time to look into the proper fix;

https://bugs.launchpad.net/bugs/1501206 [*]
^ dhcp ports reply to requests from other subnets; potential security hole;  
patch up for review; could indeed be worth looking at for RC;

https://bugs.launchpad.net/bugs/1514056 [*]
^ vlan external connectivity disrupted on ovs agent restart; patch up for  
review [tiny one, need respin]; not a regression; would be fine to see it  
fixed in RC but not a tragedy if it’s skipped;

https://bugs.launchpad.net/neutron/+bug/1528895
^ bulk rpc calls time out for l2 agent with default rpc timeout; honestly,  
I don’t believe it’s valid to have it High (there is a tunable for the  
timeout provided by oslo.messaging library); no proper fix up for review; I  
would say, we should postpone to N;

https://bugs.launchpad.net/bugs/1533034
^ exception error fix; breaks i18n freeze; I don’t believe it justifies RC  
target at all since nothing is broken;

https://bugs.launchpad.net/neutron/+bug/1541742
^ fullstack database teardown failing; workaround already merged; proper  
fix would probably require changes in db backend; should be moved to N;

https://bugs.launchpad.net/bugs/1543094
^ retry exception in ipam code; no patch in gerrit; bug comments suggest  
that a fix would involve alembic, which is not allowed anymore for M;  
should be postponed to N;

https://bugs.launchpad.net/bugs/1554332
^ agents are too aggressive fetching; base patch in gerrit, though agents  
are not touched yet; honestly, seems a bit late to do such a change since  
we would not have time to stabilize on it; I suggest we defer to N;

https://bugs.launchpad.net/bugs/1555356
^ neutron imports from tempest private code; while nice to have, I don’t  
believe it should be tracked for RC.

(Other bugs are Medium and lower.)

===

So from the list of 18 High+ bugs, only 5 of them are somewhat critical for  
release success [and even that list could be trimmed with no tragical  
consequences].

I suggest we focus on those five and cut off stable/mitaka branch when most  
of them land master [or we know that it won’t happen in a day]. For other  
stuff, I prefer we take best effort approach and backport to stable/mitaka  
before final release if fixes are in time for master, AND they really  
justify High priority, AND if they are really proved to be safe.

Thoughts?

Ihar