14:00:09 <mlavalle> #startmeeting networking
14:00:10 <openstack> Meeting started Tue Jan 15 14:00:09 2019 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:13 <openstack> The meeting name has been set to 'networking'
14:00:25 <njohnston> o/
14:00:29 <tidwellr> hi
14:00:29 <lajoskatona> o/
14:00:34 <mlavalle> o/
14:00:46 <boden> howdy
14:00:48 <rubasov> o/
14:00:53 <slaweq> hi
14:01:36 <haleyb> hi
14:02:08 <mlavalle> As usual, today's agenda is in the team's wiki: https://wiki.openstack.org/wiki/Network/Meetings
14:02:19 <amotoki> o/
14:02:23 <mlavalle> #topic Announcements
14:03:06 <mlavalle> The next milestone is Stein-3, March 4 - 8. That's a little less than a couple of months ago
14:03:58 <mlavalle> Please also remember that there is an OpenStack Foundation directors election going on
14:04:14 <mlavalle> Deadline to cast votes is this coming Friday 18th
14:04:34 <mlavalle> Many of you should have received individual emails compelling you to vote
14:04:46 <mlavalle> Any other announcements?
14:05:02 <amotoki> regarding Stein-2, we are planning to cut beta releases for stadium projects as we have no beta releases corresponding to neutron stein b1.
14:05:11 <amotoki> It would help distributor packaging a lot.
14:05:25 <mlavalle> amotoki: yeah, great that we are going to do this
14:05:28 <slaweq> amotoki++
14:05:31 <slaweq> thx
14:05:36 <amotoki> A question is whether we need another neutron stein beta release (b2) along with the above stadium project initial beta.
14:05:44 <amotoki> what do you think?
14:05:58 <mlavalle> I would say that to be on the safe side, let's do it
14:06:13 <mlavalle> that way we are 100% sure they are in synch
14:06:17 <amotoki> perhaps it is better to release them together :)
14:06:27 <mlavalle> yeap
14:06:41 <amotoki> thanks, I will prepare it tomorrow.
14:06:52 <mlavalle> thank you!
14:07:00 <amotoki> that's all from me
14:07:26 <mlavalle> #topic Blueprints
14:08:07 <mlavalle> I have roled over the blueprints we are working on to Stein-3: https://launchpad.net/neutron/+milestone/stein-3
14:08:41 <mlavalle> I have a few questions with some blueprints we were tracking during Stein-2:
14:08:58 <bcafarel> late o/
14:09:09 <mlavalle> amotoki: can we condier this one done in Stein-2: https://blueprints.launchpad.net/neutron/+spec/neutron-policy-in-code?
14:09:22 <mlavalle> or should it be rolled over to Stein-3
14:09:23 <mlavalle> ?
14:09:30 <amotoki> mlavalle: I would like to roll over to Stein-3
14:09:38 <amotoki> as neutron-fwaas polcy-in-code hasn't landed yet.
14:09:53 <amotoki> it is blocked by oslo.privsep now.
14:10:03 <mlavalle> amotoki: done
14:10:56 <mlavalle> I don't see hongbin on-line, but I am asking the same question in regards to https://blueprints.launchpad.net/neutron/+spec/ryu-framework-maintenace-transition
14:11:19 <mlavalle> I'm going to assume he will read the logs and will respond later on
14:12:08 <mlavalle> Does anyone else want to comment on an on-going blueprint?
14:12:11 <amotoki> mlavalle: hi thinks it is completed per his response in IRC http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2019-01-14.log.html#t2019-01-14T23:57:10
14:12:35 <mlavalle> amotoki: ahh, cool. Thanks
14:12:45 <njohnston> For bulk port creation speedup, I have just one change outstanding - https://review.openstack.org/#/c/624815/ - that I am still having some issues with.  Did you ever get a chance to look at that mlavalle?
14:13:08 <mlavalle> njohnston: no, sorry for that. I will take a look today
14:13:19 <njohnston> Thank you very much mlavalle
14:14:50 <mlavalle> We are having a little trouble reviewing code for https://blueprints.launchpad.net/neutron/+spec/port-mirroring-sriov-vf
14:15:31 <mlavalle> apparently the only active core reviewer in the TaaS project is yamamoto and he was travelling abroad last week
14:15:44 <mlavalle> I am going to ping him to discuss alternatives
14:16:37 <mlavalle> and probably will ask the technical committee for guidance as to how to proceed
14:17:47 <mlavalle> #topic Community goals
14:17:58 <mlavalle> We already talked about policy in code
14:18:26 <mlavalle> anything to be said on Python 3 or pre-upgrade chacks?
14:19:33 <mlavalle> ok, I take that as a no
14:19:40 <njohnston> We'll probably get a better readout on poython3 at the CI meeting in a couple of hours
14:19:40 <slaweq> pre-upgrade checkes are done IMHO
14:20:01 <mlavalle> That's great. thanks
14:20:10 <mlavalle> #topic Bugs
14:20:14 <amotoki> re: policy-in-code, I see two items to complete the blueprint.
14:20:17 <slaweq> and about python3 we are now a bit blocked because of some other CI issues
14:20:47 <amotoki> regarding the upgrade check, is anyone interested in implementing actual checks?
14:21:25 <slaweq> amotoki: I'm not aware of any
14:21:54 <amotoki> yeah, me too. one thing in my mind is to check fwaas v1 in service_plugins config and alert it.
14:22:16 <slaweq> amotoki: good idea
14:22:22 <slaweq> I can do that :)
14:22:27 <lajoskatona> amotoki: is there a kind of list what kind of checks to do?
14:22:39 <amotoki> lajoskatona: on what?
14:22:44 <amotoki> policy-in-code?
14:22:49 <lajoskatona> amotoki: upgrade checks
14:23:09 <amotoki> lajoskatona: that's the only one in my mind :p
14:23:18 <slaweq> lajoskatona: there isn't any list, community goal was to implement CLI tool and "framework" to such checks
14:23:34 <amotoki> we can collect potential checks somewhere (etherpad?)
14:23:46 <mlavalle> yeah, I was about to suggest
14:23:47 <lajoskatona> slaweq: ah, ok,
14:23:48 <slaweq> now if You have something which You would like to be checked during upgrade, it can be added as separate patch
14:24:08 <mlavalle> I can send a message to the ML with an etherpad and see if we collect ideas
14:24:15 <slaweq> mlavalle++
14:24:25 <lajoskatona> mlavalle: ++
14:24:27 <amotoki> +1
14:24:52 <mlavalle> #action mlavalle to send message to the ML to collect upgrade checks proposals
14:25:18 <mlavalle> ok, moving on
14:25:46 <mlavalle> Last week, boden was our bugs deputy and he sent yesterday his report to the ML:  http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001704.html
14:26:19 <mlavalle> I went over the bugs yesterday
14:26:33 <mlavalle> This one is high priority: https://bugs.launchpad.net/neutron/+bug/1811126
14:26:34 <openstack> Launchpad bug 1811126 in neutron "DHCPAgentOVSTestCase.test_stale_metadata_proxy_killed fails with RuntimeError: Stale metadata proxy didn't get killed" [High,Triaged]
14:26:43 <mlavalle> it's a gate failure
14:27:04 <mlavalle> slaweq: you are not working on it, are you?
14:27:13 <slaweq> mlavalle: no
14:27:33 <mlavalle> ok, if no volunteer steps up to the plate, I'll take it
14:27:42 <slaweq> mlavalle: I can add it to my list but not for this week probably
14:27:58 <slaweq> I don't think it's most urgent issue which we currently have in CI :)
14:28:29 <mlavalle> slaweq: yeah, I agree. I just wanted to highlight it in case someone volunteers
14:28:35 <slaweq> sure
14:29:36 <mlavalle> Most of the rest have owners and I will work on the RFEs this week
14:30:03 <mlavalle> boden: if you are around, is there anything else you want to highlight?
14:31:27 <mlavalle> ok, he is probably trying to get his child out of the door to go to school
14:31:41 <mlavalle> This week our bugs deputy is njohnston
14:31:49 <mlavalle> so we are in good hands
14:31:54 <njohnston> \o/
14:32:29 <mlavalle> ok, let's move on
14:32:54 <mlavalle> #topic neutron-lib
14:33:52 <mlavalle> boden might not be back yet. But before leaving he mentioned to me that the only point we wants to bring up is that he is getting ready for a new release of neutron-lib this week
14:34:22 <mlavalle> I think we were able to merge the patches he was targeting last week
14:35:05 <mlavalle> #topic CLI / SDK
14:35:31 <amotoki> I have nothing to report here
14:35:48 <mlavalle> amotoki: I have a question in regards to this RFE: https://bugs.launchpad.net/neutron/+bug/1811352
14:35:49 <openstack> Launchpad bug 1811352 in neutron "[RFE] Include neutron CLI floatingip port-forwarding support" [Undecided,New]
14:36:08 <mlavalle> This should be implemented for openstack client, right?
14:36:09 <bcafarel> on neutron-lib I think boden was asking for opinions on https://review.openstack.org/#/c/621000/ recently
14:36:34 <amotoki> IMHO it is better to implement it in OSC
14:36:38 <mlavalle> bcafarel: thanks!
14:36:55 <mlavalle> amotoki: yeah, that's what I thought. I'll clarify in the RFE
14:37:17 <amotoki> we support some *neutron* features in neutronclient OSC plugin, but it makes the bar difficult, so I would suggest to go to opensatcksdk and OSC first.
14:37:35 <amotoki> I will comment it to the bug later.
14:37:41 <lajoskatona> amotoki, mlavalle: in that case, if we implement in osc, it can be backported?
14:37:43 <mlavalle> thanks amotoki
14:38:03 <amotoki> lajoskatona: i don't think so as it is a feature
14:38:24 <lajoskatona> amotoki: the reported reported for Rocky
14:38:54 <amotoki> lajoskatona: do you mean the server side supports it in rocky?
14:38:57 <lajoskatona> so it must be clear for him/her that it will be done on master
14:39:18 <lajoskatona> amotoki: no, if I understand well the CLI support for FIP port forwarding
14:40:05 <lajoskatona> amotoki: I read again, and perhaps the question is not for rocky, sorry....
14:40:17 <mlavalle> cool, thanks
14:40:29 <mlavalle> #topic On demand agenda
14:40:40 <mlavalle> slaweq: you added a topic to the agenda
14:40:46 <mlavalle> the stage is yours
14:40:50 <slaweq> thx mlavalle
14:41:02 <slaweq> I recently found interesting topic on ML
14:41:15 <slaweq> http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001374.html
14:41:32 <slaweq> and I wanted to ask people what do You think about doing something like that in Neutron
14:41:56 <slaweq> IMO it would be useful to have such possibility to set priorities for some patches and review them first
14:42:20 <slaweq> especially when we are close to release deadline or we have some critical gate failures
14:42:47 <njohnston> I've been following that ML thread as well; it does seem like it wouldn't be too much overhead.
14:43:03 <slaweq> here is example of dashboard with such priorities for cinder: https://tiny.cc/CinderPriorities
14:43:14 <njohnston> And it's not like all patches would need to be prioritized; only those that deviate from the median urgency level.
14:43:33 <slaweq> njohnston: yes, I agree
14:43:43 <amotoki> generally I agree it sounds useful. what I am not sure is how we use it.
14:44:04 <slaweq> amotoki: I was thinking about something like this cinder dashboard
14:44:18 <slaweq> where You can find what patches are most important to review
14:44:21 <boden> seems logical as long as we are all on the same page about which/when patches get prioritized
14:44:22 <mlavalle> who has the right to set priority?
14:44:23 <amotoki> slaweq: do you have a handy link?
14:44:38 <slaweq> amotoki: link to what?
14:44:53 <slaweq> mlavalle: it might be configured in gerrit who can set this priorities
14:45:03 <amotoki> https://review.openstack.org/#/q/project:openstack/cinder+status:open explains me a lot :)
14:45:03 <slaweq> it migth be only You or drivers team
14:45:23 <mlavalle> slaweq: and do you know what convention other teams have adopted?
14:45:54 <slaweq> I don't think there is any general convention as for now
14:46:24 <lajoskatona> mlavalle: nova for example has an etherpad with a list of patches to review that given week
14:46:51 <mlavalle> the other question I have is: is there a sense among the team that we are not revieiwing important patches in a timely manner?
14:47:03 <mlavalle> in other words, do we have a problem to fix?
14:47:16 <lajoskatona> it works like a FIFO, the top items are reviewed and the next batch goes to top next week
14:47:18 <lajoskatona> or similar
14:47:36 <slaweq> mlavalle: I don't think we have problem to fix here, I just though that maybe it could be useful improvement :)
14:47:46 <slaweq> and wanted to ask for opinions
14:47:46 <mlavalle> In principle, I like the idea of the new tool in Gerrit, but do we actually need it?
14:48:45 <mlavalle> in seems low overhead, but there is going to be some overhead anyways
14:48:53 <njohnston> We don't need it, but it might help.  For example, we could put a +2 priority on gate-fix changes, and that would raise awareness of them without a ML message/
14:49:31 <slaweq> njohnston++
14:49:48 <lajoskatona> njohnston +
14:50:02 <mlavalle> ok, here's what I propose. Let's find out how other teams are handling it and we revisit next week. does that work?
14:50:27 <slaweq> so IMO lets think about it for a while and maybe get back to it on next meeting if more people will have some thoughts about it
14:50:32 <slaweq> mlavalle++
14:50:36 <slaweq> You were faster
14:50:45 <mlavalle> LOL
14:50:59 <mlavalle> thanks for bringing this up slaweq!
14:51:06 <slaweq> yw
14:51:24 <mlavalle> anything else we should discuss today?
14:52:15 <mlavalle> ok, thanks for attending
14:52:20 <mlavalle> Have a great week!
14:52:26 <mlavalle> #endmeeting