21:01:33 <armax> #startmeeting networking
21:01:34 <openstack> Meeting started Mon Feb  8 21:01:33 2016 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:37 <openstack> The meeting name has been set to 'networking'
21:01:38 <johnsom> o/
21:01:39 <ihrachys> o/
21:01:40 <njohnston> o/
21:01:42 <HenryG> o/
21:01:42 <dougwig> o/
21:01:43 <mestery> o/
21:01:44 <mhickey> o/
21:01:50 <neiljerram> hi
21:01:50 <hichihara> o/
21:02:04 * mestery thinks if we're using meeting start to count people we're doing it wrong
21:02:13 <salv-orlando> aloha
21:02:27 <ihrachys> mestery: we are doing it wrong if we count
21:02:36 * njohnston just likes little ASCII people.  It reminds me of IRC in 1995.
21:02:45 <dasm> mestery: ihrachys: stats... stats everywhere
21:02:47 <Sam-I-Am> hi
21:02:52 <armax> there’s not much on the agenda this week
21:02:56 <armax> by the looks of it
21:02:58 <russellb> hi
21:03:08 <dougwig> we could bikeshed the stadium for at least an hour.
21:03:17 <johnsom> It is the irc of the 90's....
21:03:45 <russellb> dougwig: :/
21:03:48 <armax> #topic Announcements
21:04:00 <armax> We
21:04:07 <armax> are well in the M3 window
21:04:15 <armax> as you guys are fully aware
21:04:31 <armax> during the past two weeks we did a checkpoint on blueprints and RFEs
21:05:11 <armax> as it pains me to say, some stuff will have to be removed from Mitaka
21:05:31 * mestery hands armax a kleenex
21:05:40 <russellb> S.O.P.
21:05:47 * regXboi calls for the crowbar
21:05:57 <armax> I’ll be going over the list this week to see what can reasonably make Mitaka and what can’t
21:06:38 <armax> I would like to remind you that if you are an approver/assignee of a blueprint/rfe
21:06:50 <armax> to work with your peer to get things moving as much as you can
21:07:02 <armax> be proactive
21:07:18 <dougwig> https://launchpad.net/neutron/+milestone/mitaka-3
21:07:50 <armax> bear in mind
21:08:58 <armax> should stuff gets out of Mitaka, we’ll still allow progress for now
21:09:15 <armax> but any patch that includes a release note will be blocked
21:09:31 <russellb> so just don't add a release note for your feature?
21:09:38 * ihrachys runs to remove release notes from his patches
21:09:39 <dasm> russellb: ++
21:09:53 <armax> that’s funny ah ah
21:09:58 <salv-orlando> russellb: if you do that it's not the patch that gets blocked, but the authro
21:10:05 <salv-orlando> blocked forever
21:10:10 <russellb> harsh
21:10:13 <salv-orlando> physically blocked
21:10:13 <mestery> super harsh
21:10:26 <xgerman> send to MN
21:10:30 <salv-orlando> texas chainsaw style
21:10:34 <xgerman> and put in an igloo
21:11:43 <mestery> harsh
21:12:06 * armax waits an extra minute for people to finish off their remarks
21:12:09 <dougwig> sheesh, dark meeting today.
21:12:09 <russellb> (sorry for the interruption)
21:12:26 <mhickey> I thought this meeting was supposed to be "light entertainment"?!
21:12:27 * mestery grows up
21:13:19 <armax> ok
21:13:22 <armax> minute up
21:13:37 <armax> #topic bugs
21:14:05 <armax> mhickey: we had a discussion on gate stability this week
21:14:08 <armax> on the ML
21:14:49 <mhickey> armax: ok; do you have the thread?
21:14:52 <armax> there are a few gate failure offenderes
21:14:57 <armax> *offenderes
21:15:01 <armax> offenders!
21:15:22 <armax> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/085631.html
21:15:27 <mhickey> thanks
21:15:33 * njohnston thanks everyone for helping him bug deputy last week, especially sc68cal, ajo, and blogan.
21:15:42 <armax> so IPv6 is not behaving well in the gate
21:16:04 <armax> haleyb had a patch up to move some of tests to the periodic queue
21:16:14 <armax> that helped
21:16:24 <armax> but I still see failures
21:16:25 <Sam-I-Am> njohnston: you got the fun mtu bugs :)
21:16:44 <armax> as a team
21:16:51 <armax> we gotta figure out to keep this list to 0
21:16:54 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.tag=gate-failure
21:17:33 <armax> especially now that we’re going into the busy period of the release
21:18:01 <armax> linuxbridge has been flaky recently too, and kevinbenton helped on that front too
21:18:36 <armax> so I am calling for arms here…anyone interested in IPv6 as well as Linux Bridge, please make sure stability issues are given priority
21:18:44 <sc68cal> I think kevin's patch may have fixed the flakyness. We're at 0% failure for today
21:18:46 <armax> otherwise we’ll have to demote this stuff from the gate and let it rot
21:18:58 <armax> sc68cal: super kevinbenton strikes again
21:19:14 <sc68cal> re dropping stuff and letting it rot - then my joke about nobody caring about IPv6 will be shown to be not a joke
21:19:22 <sc68cal> so yeah let's not make my joke come true
21:19:32 <armax> mhickey: care to add anything?
21:19:41 <ihrachys> armax: what's the linuxbridge one? I miss details. and can work with Andreas on looking into that one. is that the one breaking stable for a while in the past?
21:19:53 <mhickey> its njohnston that was the weeks deputy
21:20:07 <mhickey> I am only starting
21:20:08 <sc68cal> ihrachys: it was https://review.openstack.org/#/c/276519/
21:20:25 <sc68cal> to get context
21:20:30 <armax> ihrachys: we saw a surge of failures on the linuxbridge job
21:20:48 <armax> ihrachys: are you saying that the job is persistently broken on stable branches?
21:21:03 <ihrachys> armax: ok I thought that was stable only (haven't seen any on master myself)
21:21:20 <ihrachys> armax: no it was actually cured lately I think. not sure how (was traveling the whole week before)
21:21:52 <armax> ok
21:23:07 <armax> njohnston: anything you would like to add?
21:23:26 <njohnston> armax: The main LB bug that came was to track to MTU issues (https://bugs.launchpad.net/bugs/1542108), the other LB bugs (https://bugs.launchpad.net/neutron/+bug/1542923, https://bugs.launchpad.net/neutron/+bug/1542972), while notable, didn't strike me as gate-busters
21:23:29 <openstack> Launchpad bug 1542108 in neutron "MTU concerns for the Linux bridge agent" [High,Confirmed] - Assigned to Sean M. Collins (scollins)
21:23:30 <openstack> Launchpad bug 1542923 in neutron "Linuxbridge agent failed to start when bridge_mappings is given" [Undecided,New] - Assigned to Slawek Kaplonski (slaweq)
21:23:31 <openstack> Launchpad bug 1542972 in neutron "linux bridge device processing loop breaks on removals" [High,In progress] - Assigned to Kevin Benton (kevinbenton)
21:25:15 <armax> ok thanks
21:25:26 <mhickey> armax: I have 2 to add for today..
21:25:33 <armax> mhickey: go for it
21:25:51 <mhickey> https://bugs.launchpad.net/neutron/+bug/1543040 and https://bugs.launchpad.net/neutron/+bug/1543094
21:25:53 <openstack> Launchpad bug 1543040 in neutron "neutron.tests.unit.agent.linux.test_async_process.TestFailingAsyncProcess.test_failing_async_process_handle_error_once failed in Liberty periodic job" [High,In progress] - Assigned to Nir Magnezi (nmagnezi)
21:25:54 <openstack> Launchpad bug 1543094 in neutron "[Pluggable IPAM] DB exceeded retry limit (RetryRequest) on create_router call" [Undecided,New] - Assigned to Salvatore Orlando (salvatore-orlando)
21:26:19 <ihrachys> the 1st is a test only issue and liberty only; just need a backport of an existing fix.
21:26:32 <mhickey> ihracchys: thanks
21:26:55 <mhickey> the other salv-orlando is looking at
21:27:11 <armax> mhickey: thanks
21:28:03 <armax> from now on let’s be conscious as to what bug fix needs to target M3
21:28:34 <ihrachys> should we stop merging untargeted fixes? or should we just be informally mindful?
21:29:22 <armax> ihrachys: both?
21:29:23 <armax> :)
21:29:55 <armax> ideally we target stuff that we know is gonna hurt the release if it doesn’t merge
21:30:21 <armax> I wonder if rossella_s1’s script is widely used amongst team members?
21:31:04 <dougwig> what script/where?
21:31:08 <ihrachys> not by me, sorry.
21:31:22 <armax> dougwig: it’s a script in the repo
21:31:25 <armax> under tools
21:31:36 <armax> it generates a gerrit dashboard
21:31:57 <hichihara> https://github.com/openstack/neutron/blob/master/tools/milestone-review-dash.py
21:32:00 <armax> that contains patches targeting release items and high priorities fixes
21:32:04 <armax> hichihara: that’s the one!
21:32:07 <armax> hichihara: thanks
21:32:20 <hichihara> armax: :)
21:33:13 <armax> any taker for next week deputy duty?
21:33:31 <regXboi> I thought that was covered last week?!?!
21:33:41 <armax> we got this week covered
21:33:50 <armax> not the next, I am being proactive!
21:33:56 <regXboi> ah .... I get it now
21:34:00 <armax> I drink my own kool-aid you know?
21:34:23 <dasm> i volunteer
21:34:34 <armax> dasm: cool
21:34:50 <mhickey> btw, kudos to njohnston for great steps on starting out as a "green" deputy: https://etherpad.openstack.org/p/neutron-bug-deputy
21:34:52 <armax> dasm: thanks
21:35:00 <mhickey> dasm: ++
21:35:02 <dasm> mhickey: exactly. njohnston ++
21:35:06 <ihrachys> armax: I thought rossella_s1 was to cover it?
21:35:11 <ihrachys> armax: as per prev meeting.
21:35:25 <armax> mhickey, njohnston you may want to turn that into a diff to the devref version of it
21:35:46 <armax> http://docs.openstack.org/developer/neutron/policies/bugs.html#bug-screening-best-practices
21:35:59 <armax> I see no reason why we should keep this in two separate sources
21:36:08 <mhickey> armax: ok, can sync with njohnston biut he did all the good work :)
21:36:14 <mhickey> *but
21:36:18 <njohnston> armax: Yes sir.
21:36:53 <mhickey> njohnston: :)
21:36:54 <armax> thanks folks
21:37:40 <armax> ihrachys: um, that might have slipped through the cracks, I’ll double check
21:38:06 <armax> #topic Docs
21:38:17 <armax> before I had over to Sam-I-Am
21:38:25 <Sam-I-Am> howdy
21:38:29 <armax> I would like to state the obvious
21:39:04 <armax> but a feature is not complete without docs
21:39:11 <armax> so if you have something targeted to you
21:39:19 <armax> either as approver or submitter
21:39:23 <armax> look for Docs patches
21:39:40 <armax> or don’t forget to submit them/provide support to docs folks
21:39:48 <Sam-I-Am> and if you don't, you have to deal with me :)
21:39:49 <armax> our users will love you for it
21:40:34 <russellb> or hate you, depending
21:40:35 <armax> to this aim, any feature without at least a barebone doc reference will not be signed off as complete for Mitakta
21:40:42 <mlavalle> Sam-I-Am: that's a strong incentive ;-)
21:40:44 <Sam-I-Am> no docs, no release? :)
21:40:44 <njohnston> What is the best way to tie those together, given that the changes may be in openstack-manuals or api-guide or cli guide etc?  You can use Depends-On tag to make sure that they don't merge before the primary patch, but there's no way to reverse that association, i.e. see all the docs patches depending on this primary code patch.
21:40:46 <armax> Mitaka
21:41:06 <armax> I’d say we can be lax about this
21:41:36 <armax> because tying commis like this can be a bit of a pain
21:41:41 <armax> commits
21:41:49 <ihrachys> :D
21:41:52 <njohnston> ok, making sure there wasn't a customary way to do that
21:42:10 <Sam-I-Am> some of this might need to be managed in a less mechanical way
21:42:12 <armax> but I’d say before we mark a BP Implemeted or a RFE release we should at least have a doc reference
21:42:32 <armax> and we should paste it either on the whiteboard or the bug report page
21:42:48 <armax> bear in mind that toda
21:42:49 <armax> y
21:42:53 <Sam-I-Am> whomever is managing the bp/spec should be able to track completion of all the bits, and feel free to drag me into it if you're not sure what constitutes as usable docs.
21:43:25 <Sam-I-Am> 'how to run this in a devstack all-in-one' is not docs.
21:43:26 <armax> patches that have a DocImpact in the message
21:43:33 <armax> will generate a bug in this list:
21:43:35 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=doc
21:43:48 <sc68cal> no docs < some docs < good docs
21:44:02 <armax> these bugs can have multiple fixes
21:44:03 <sc68cal> so, even some docs is a start
21:44:15 <armax> either neutron iself, openstack-manuals, api-site or all of them
21:44:34 * armax hands over the mike to Sam-I-Am
21:44:39 <Sam-I-Am> woo
21:44:50 <Sam-I-Am> if its developer-oriented docs, it goes into the devref
21:45:12 <Sam-I-Am> if an operator would use it, it goes into openstack-manuals in the networking guide at a minimum... possibly api or config-ref if it impacts those things
21:45:23 <Sam-I-Am> thats more or less the separation between those places
21:45:52 <Sam-I-Am> tl;dr ... if it involves deployment or how-to-use feature X, throw it in the networking guide
21:46:07 <armax> Sam-I-Am: and if you don’t know, ask
21:46:13 <Sam-I-Am> yeah, pretty much
21:46:17 <Sam-I-Am> y'all know how to find me
21:46:19 <armax> and we’ll happily you wind you up in circle
21:46:30 <armax> until you get frustrated and move on
21:46:48 <dasm> one more thing about docs. i asked Anne Gentle about it: http://lists.openstack.org/pipermail/openstack-dev/2016-February/085890.html
21:47:14 <Sam-I-Am> decent docs = more adoption of X and less frustration with X
21:47:30 <armax> dasm: ok
21:47:51 <Sam-I-Am> api docs will hopefully be easier soon-ish
21:48:38 <Sam-I-Am> other than adding to armax's comments, not much from the docs side. still trying to contribute to the networking guide.
21:49:00 <armax> Sam-I-Am: thanks
21:49:03 <Sam-I-Am> i know mhickey has something in flight in openstack-manuals
21:49:17 <Sam-I-Am> i'll try to help out with those things when i can
21:49:46 <mlavalle> Sam-I-Am: I am also writing a chapter about DNS integration for the networking guide
21:49:57 <mhickey> Sam-I-Am: sure; have review comments to get to thids week
21:50:02 <mhickey> *this
21:50:10 <Sam-I-Am> mlavalle: cool
21:50:49 <armax> ok
21:50:58 <armax> #topic Open Discussion
21:51:08 * dougwig opens his paint jars.
21:51:16 <mlavalle> dougwig: lol
21:51:18 * Sam-I-Am subliminally chants fix mtu
21:51:51 <armax> MTU issues was discussed during last meeting, was it not?
21:52:04 <ihrachys> not really?
21:52:04 <armax> there’s nothing flagged on the agenda for today’s meeting
21:52:06 <russellb> i think Sam-I-Am is scarred
21:52:15 <Sam-I-Am> armax: bugs are filed now as you asked me to do
21:52:18 <salv-orlando> armax: yeah but dougwig's paint will dry out, and I have my paintbrush ready
21:52:46 <Sam-I-Am> it'd be really nice to fix it for mitaka
21:52:49 <armax> 8 minutes in not nearly enough to paint anything serious
21:52:51 <russellb> salv-orlando: dougwig guys, bikeshedding is debating the color, not actually *doing* the paining.  that's far too productive.
21:53:11 <armax> russellb has a point
21:53:20 * dougwig closes his paint jars. and cries.
21:53:24 <sc68cal> lol
21:53:28 <salv-orlando> we are practical bike shedders
21:53:34 <armax> on that note, I’d rather give you 7 minutes back so that you can go and do something productive
21:53:37 <john-davidge> Can we mention #link https://review.openstack.org/#/c/265041 quickly?
21:53:49 <russellb> looks like you just did :)
21:54:00 <john-davidge> I’d rather not expand the bodged together initiate_gmr() call to every cmd file unless really necessary
21:54:15 <armax> john-davidge: agreed
21:54:22 <ihrachys> john-davidge: so instead you propose to drop oslo.reports? that's gross.
21:54:28 <john-davidge> Would it be teriible to pull out GMR completely and put the burden on the original submitter to fix the problem before we merge it again?
21:54:54 <russellb> i'd certainly rather not
21:54:59 <salv-orlando> I mean is the problem a warning line on the console?
21:55:05 <ihrachys> yes.
21:55:09 <john-davidge> salv-orlando: yes
21:55:10 <russellb> having first hand seeing *HUGE* benefits that the report can provide when trying to debug a bizarre lockup
21:55:26 <ihrachys> apparently dibbler relies on scripts not writing anything there
21:55:34 <armax> john-davidge: is it possible to catch it in the neutron-pd-notify
21:55:48 <salv-orlando> ah so john-davidge was ironic when suggesting of pulling the whole feature because of this ;)
21:55:56 <armax> I mean is there a chance to neutralize the effect of the warning on the client that’s affected?
21:55:58 <salv-orlando> sorry I thought he was serious for a second
21:56:12 <ihrachys> john-davidge: so, what's the actual deal of having it in each cmd module? yes, it's not ideal, but we failed to find a better way.
21:56:14 <russellb> same..
21:56:22 <armax> I must admit I am not 100% up to speed to come up with a good answer
21:56:39 <john-davidge> armax: Posiibly. I havent found one so far but I could trying digging again
21:57:24 <armax> I’d personally rather avoid the sprinkling of method calls the way you did
21:57:31 <armax> it’s obviously prone to error
21:57:40 <john-davidge> ihrachys: It seems to me that there must be a better, single place that we can initiate the logging for GMR iwthout needing to call a function in every single cmd file. But as we both discovered if there is one it isnt obvious :(
21:58:03 <armax> can we ask the guru folks?
21:58:05 <ihrachys> john-davidge: yeah, because for that you need to parse config files and initialize logging
21:58:13 <armax> perhaps they have an answer on how to address this No handlers could be found for logger "oslo_reports.guru_meditation_report" error
21:58:22 <armax> that gets thrown
21:58:32 <john-davidge> armax: That would be a great idea, who can we ping about that?
21:58:35 <ihrachys> armax: that's a good idea. we can try someone from nova.
21:58:49 <armax> someone must have stumbled upon it before
21:58:53 <armax> dunno
21:59:10 <ihrachys> john-davidge: let's say we start from oslo.reports core folks
21:59:15 <armax> going in the oslo_reports repo should give you a lead
21:59:27 <armax> ok time is up
21:59:32 <armax> #endmeeting