21:00:53 <armax> #startmeeting networking
21:00:54 <openstack> Meeting started Mon Aug 22 21:00:53 2016 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:55 <oanson> Hi
21:00:57 <openstack> The meeting name has been set to 'networking'
21:00:58 <trevormc> o/
21:01:02 <njohnston> o/
21:01:05 <yamahata> hi
21:01:07 <armax> we can keep the meeting short if need be
21:01:26 <armax> we can start off with announcements
21:01:30 <armax> #topic Announcements
21:01:32 <armax> The gate is in trouble
21:01:46 <armax> Stop merging and recheck with care
21:02:09 <dougwig> it affects neutron tempest jobs, or more than that?
21:02:26 <armax> dougwig: tempest and unit tests so far
21:02:33 <dasm> what is the root cause? or is it multiple reasons?
21:02:44 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.tag=gate-failure
21:02:52 <Sam-I-Am> moo.
21:02:56 <armax> for the tempest failure we have already got a root cause nailed down
21:03:26 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=NEW&field.status%3Alist=INPROGRESS&field.tag=gate-failure
21:03:57 <armax> I just noticed the unit test failures in changes that were in the gate queue
21:05:44 <armax> we also experienced a break last Friday due to a tempest change
21:06:03 <armax> but that has been dealt with
21:06:19 <armax> pending change https://review.openstack.org/#/c/358753/ should bring the tempest side of the house back to sanity
21:06:44 <armax> but the change just got stung by a random unit test failure
21:06:55 <armax> so it’ll have to go through the queue once more
21:07:16 <armax> however with the recent instability who knows how long it’ll take to merge
21:07:35 <dougwig> yep, the gate random churn has been really high lately.
21:08:07 <armax> right now we should all take the time to go over gate failures and gate failure fixes and make sure we have everything nailed down
21:09:04 <armax> let’s make sure the confirmed list of gate failure is empty
21:09:05 <armax> please
21:09:09 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.tag=gate-failure
21:10:46 <armax> we should also go through http://status.openstack.org/elastic-recheck/ and categorize any uncategorized failure
21:10:56 <armax> #link http://status.openstack.org/elastic-recheck/data/integrated_gate.html
21:11:55 <armax> we should give priority review to gate failure fixes, let’s take aside refactoring and cosmetic patches for a little bit
21:12:45 <armax> anyone else has anything to add?
21:13:01 <armax> one other announcement I wanted to make was regarding the mid-cycle
21:13:29 <armax> for those of you who did not manage to join, we’ll be sending out a report by the end of the week
21:14:21 <armax> also this week is non-client library freeze
21:14:34 <armax> whereas next week is Newton feature freeze
21:14:45 <armax> which entails requirements freeze
21:15:14 <dougwig> HenryG: i think we'll want a final lib release this week.
21:15:20 <armax> anything that fails to get into libraries and client projects is deferred to Ocata unless there’s a good reason for an exception
21:15:45 <armax> dougwig, HenryG: ok, let’s make sure we have something in gerrit by the end of today
21:15:54 <armax> HenryG is in CEST this week I think
21:16:23 <njohnston> Is python-neutronclient considered a 'non-client library' at this point?
21:16:27 <dougwig> armax: when is the due date for the patch to releases?  i'm not expecting any new gerrit patches into the lib, but a few existing ones, and the ones we merged last week.
21:16:35 <dougwig> if it's today, i'll submit that later.
21:17:10 <armax> dougwig: ok so do you see as a simple refresh?
21:17:41 <armax> njohnston: I consider it a client library
21:17:52 <njohnston> armax: Thanks for the clarification
21:18:12 <dougwig> armax: no, we have base model stuff and one other big one from last week.  it has a few fixes pending, all submitted already
21:18:19 <dougwig> i'd like to get those in this week, then release.
21:18:27 <armax> ok
21:19:04 <armax> let me ping you offline to see to get a more detailed picture
21:19:23 <dougwig> ok
21:20:37 <armax> if there’s nothing else, I’d rather take the 40 minutes back and crack down on some of the issues that have popped up lately
21:21:01 <mlavalle> ++
21:21:02 <dasanind_> armax: the clean up api-ref should be completed this week then?
21:21:13 <armax> dasanind_: it’s gonna have to be ongoing
21:21:15 <oanson> I have a question about the transaction guard around the port methods.
21:21:22 <armax> oanson: shoot
21:21:28 <oanson> In ML2. From  https://review.openstack.org/#/c/275110/
21:21:55 <oanson> I was wondering what is the long term plans to allow external L3 service plugins to call these methods from within transactions
21:22:07 <oanson> Instead of the GUARD_TRANSACTION=false workaround.
21:22:30 <armax> kevinbenton has promised us a fix, but before doing that we need to disentagle the code a bit
21:22:33 <dasanind_> armax: as you mentioned the neutron-lib will freeze this week. so the api-ref's that will not be completed will go in  the next release then?
21:22:47 <armax> dasanind_: correct
21:22:56 <dasanind_> armax: thank you
21:23:05 <armax> kevinbenton: ^ wanna elaborate further?
21:23:58 <kevinbenton> there is no long term to allow that
21:23:59 <armax> oanson: feel free to reach to kevinbenton in the #openstack-neutron channel
21:24:11 <kevinbenton> it's fundamentally incompatible with ML2
21:24:38 <kevinbenton> the fix is going to be to correctly manage the life-cycle of a port independent of a DB transaction
21:25:08 <armax> kevinbenton: right, thanks for clearing that up
21:25:18 <oanson> kevinbenton, thanks.
21:25:35 <armax> oanson: calling core plugin methods within transactions has never been a good thing
21:25:36 <dougwig> dasanind_: but, the api-ref work will continue without a pause.  it doesn't need a pypi release to continue the work.
21:26:06 <oanson> armax, I see. I wanted to understand the bigger picture before re-writing some of our code.
21:26:29 <armax> and must be prevented
21:27:11 <dasanind_> dougwig: makes sense
21:27:15 <armax> oanson: the problem stems from the fact that core plugin methods may execute actions that cannot be rolled back
21:27:22 <armax> like backend operations
21:27:56 <armax> ok
21:27:59 <oanson> So in any case plugins should be given a chance to execute their code before these operations.
21:28:18 <oanson> So that if the plugins fail, they have a chance to roll back?
21:29:02 <armax> I am not sure I understand the question
21:30:22 <oanson> The issue we ran into is in the router_add_interface method in l3 service plugin. We wanted to tie the version modification to the router modification's session, so that it'd be atomic.
21:30:44 <armax> oanson: do you have a patch?
21:30:50 <armax> we can take the discussion on the review itself
21:30:57 <armax> I’d like to end the meeting
21:31:00 <oanson> armax, that's code that's already merged
21:31:12 <oanson> But we can take the discussion off-line.
21:31:26 <armax> oanson: that code that you’re looking at must be rewritten
21:31:40 <oanson> armax, that's what I feared.
21:31:45 <armax> #endmeeting