Armando M. <[email protected]> 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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
