14:01:07 <slaweq> #startmeeting networking
14:01:08 <openstack> Meeting started Tue Jun  4 14:01:07 2019 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:09 <slaweq> hi
14:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:12 <openstack> The meeting name has been set to 'networking'
14:01:14 <lajoskatona> Hi
14:01:16 <mlavalle> o/
14:01:28 <tidwellr> hi
14:02:07 <rubasov> o/
14:02:08 <bcafarel> hello
14:02:23 <slaweq> #topic Announcements
14:02:46 <njohnston> o/
14:02:49 <slaweq> Milestone Train-1 is this week
14:02:58 <slaweq> #link https://releases.openstack.org/train/schedule.html
14:03:33 <slaweq> mlavalle: do we need to release new versions this week then?
14:03:43 <davidsha> o/
14:03:58 <mlavalle> yes, that's the agreement we did last ccyle
14:04:04 <mlavalle> release stable branches
14:04:17 <slaweq> that's what I thought
14:04:33 <slaweq> so amotoki and mlavalle You will do this, right?
14:04:43 <mlavalle> haleyb did that last time
14:04:46 * haleyb arrives after being in nickserv detention
14:05:14 <haleyb> i actually started stable patches, but think there are one or two more things to merge in each branch
14:05:14 <mlavalle> haleyb: will you create the patches for stable branches this time around?
14:05:25 <mlavalle> cool, thanks!
14:05:40 <haleyb> so yes, i can do it, i'll ping people about getting reviews done on stragglers
14:05:54 <slaweq> haleyb: thx
14:05:57 <mlavalle> :-)
14:06:20 <slaweq> next one then
14:06:28 <slaweq> Just a reminder: Open Infrastructure Summit CFP Open - Deadline: July 2
14:06:35 <slaweq> link: http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006262.html
14:07:13 <slaweq> so if You want to have propose some talk for next Summit, it's time to prepare proposal :)
14:07:51 <slaweq> another reminder, is someone missed it on previous meeting: Photos from recent Denver PTG are available at:
14:07:58 <slaweq> #link https://www.dropbox.com/sh/fydqjehy9h5y728/AAC1gIc5bJwwNd5JkcQ6Pqtra/Neutron?dl=0&subfolder_nav_tracking=1
14:08:21 <slaweq> and last reminder
14:08:23 <slaweq> Train PTG summary:
14:08:30 <slaweq> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006408.html
14:08:49 <slaweq> any other announcements?
14:09:07 <mlavalle> none from me
14:09:59 <slaweq> ok, lets move on then
14:10:07 <slaweq> #topic Blueprints
14:10:30 <slaweq> This is what we have planned for T-1:
14:10:36 <slaweq> #link https://launchpad.net/neutron/+milestone/train-1
14:11:18 <mlavalle> on this topic I have to say that last week we completed https://blueprints.launchpad.net/neutron/+spec/smart-nic-ovs
14:11:48 <slaweq> I just wanted to ask if we need anything else for that one
14:11:51 <slaweq> thx mlavalle
14:11:59 <mlavalle> this is the patch that completed the feature: https://review.opendev.org/#/c/586252/
14:12:12 <mlavalle> it merged last week
14:12:40 <mlavalle> on https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
14:13:17 <mlavalle> we are making good progress
14:13:25 <mlavalle> we are merging patches
14:13:39 <munimeha1> can we add this one to train-1 also https://bugs.launchpad.net/neutron/+bug/1458890
14:13:40 <openstack> Launchpad bug 1458890 in neutron "[RFE] Add segment support to Neutron" [Wishlist,Triaged] - Assigned to Carl Baldwin (carl-baldwin)
14:13:40 <mlavalle> and there are several more in the pipeline
14:14:03 <munimeha1> based on changes for routed networks to support multiple segments
14:14:17 <munimeha1> we can also levereage same to enhance sriov
14:14:33 <mlavalle> thanks to ralonsoh and njohnston for their hard work on this
14:15:08 <slaweq> mlavalle: yes, I saw couple of patches merged/close to merge related to this one
14:15:22 <slaweq> and it looks that it's going pretty easy so far :)
14:15:28 <slaweq> (too easy :P)
14:15:40 <njohnston> we're plucking the low hanging fruit first :-)
14:15:43 <mlavalle> well, I think we are starting to hit the difficult ones
14:16:14 <mlavalle> here's an example for last night: https://review.opendev.org/#/c/662869/
14:16:40 <mlavalle> so don't let your guard down and stay ready for a long fight
14:16:47 <mlavalle> ;-)
14:16:49 <slaweq> :)
14:16:50 <njohnston> amen brother
14:17:00 <slaweq> thx You all for working on this
14:17:33 <mlavalle> munimeha1: regarding multiple segments in routed networks, we already have that as a target: https://blueprints.launchpad.net/neutron/+spec/multiple-segment-per-network-per-host
14:17:43 <slaweq> munimeha1: according to Your question, I think that we can only add Your rfe to T-2 as T-1 is this week :)
14:17:48 <slaweq> mlavalle: what do You think?
14:18:02 <munimeha1> ok T-2 is fine
14:18:04 <munimeha1> thanks
14:18:24 <mlavalle> munimeha1: but look at the blueprint that I just mentioned ^^^^
14:18:30 <munimeha1> sure
14:18:36 <mlavalle> that is what you are talking about, right?
14:18:45 <munimeha1> yes
14:19:01 <mlavalle> so it is already targeted for T-1. it is going to slip to T-2
14:19:19 <mlavalle> bt you can help revieiwing the spec: https://review.opendev.org/#/c/657170
14:19:24 <munimeha1> sure
14:19:28 <mlavalle> which I ask others to do as well
14:19:31 <slaweq> speaking about https://blueprints.launchpad.net/neutron/+spec/multiple-segment-per-network-per-host there is patch https://review.opendev.org/#/c/657170 waiting for review also
14:19:38 <mlavalle> it is my goal for this week
14:19:55 <mlavalle> slaweq: right. thanks for bringing it up
14:20:05 <slaweq> You were faster mlavalle :)
14:20:25 <munimeha1> Did you notice this one is related https://review.opendev.org/#/c/656885/
14:21:24 <mlavalle> munimeha1: yes, that one is a debt that Nova has owed to us for a long time
14:21:27 <lajoskatona> and don't forget the bug for routed networks: https://bugs.launchpad.net/neutron/+bug/1828543
14:21:28 <openstack> Launchpad bug 1828543 in neutron "Routed provider networks: placement API handling errors" [Medium,New] - Assigned to Lajos Katona (lajos-katona)
14:21:59 <mlavalle> lajoskatona: thanks. I owe you a response to an email. Haven't forgotten
14:22:20 * mlavalle was feeling bad this morning while walking the dog
14:22:21 <lajoskatona> mlavalle: thanks, now in keystoneauth there is a fix for exception handling
14:22:48 <slaweq> so I will update this BP https://blueprints.launchpad.net/neutron/+spec/multiple-segment-per-network-per-host to include links to all those things there, ok for You?
14:22:51 <lajoskatona> mlavalle: so I continue to see what is missing to make this working again and add tests
14:23:05 <mlavalle> cool, thanks
14:23:07 <lajoskatona> slaweq: ok for me,  thanks
14:23:15 <slaweq> ok, I will do it after the meeting
14:23:20 <slaweq> lets move on then
14:23:28 <slaweq> we have also BP https://blueprints.launchpad.net/neutron/+spec/event-notifier-ironic
14:23:42 <slaweq> and we have already merged https://review.opendev.org/#/c/658787/
14:23:52 <slaweq> which looks like the only needed thing on our side
14:24:02 <slaweq> do You know if we can consieder it as done maybe?
14:24:10 <slaweq> or what else is missing on our side for it
14:24:31 <mlavalle> hang on...
14:25:14 <mlavalle> I think that's it
14:25:42 <mlavalle> we finished that one
14:25:50 <slaweq> great, so mlavalle can You update BP and set proper status for it?
14:25:58 <mlavalle> yes I will
14:26:03 <slaweq> thx a lot mlavalle
14:26:15 <slaweq> ok, lets move on
14:26:20 <mlavalle> and I will also go over the PTG summary this week
14:26:36 <mlavalle> there are other BPs in there that we need to add to the dashboard
14:26:53 <slaweq> thx mlavalle
14:27:05 <slaweq> #topic Bugs
14:27:29 <slaweq> last week amotoki was our bug deputy
14:27:35 <slaweq> he sent summary http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006850.html
14:28:22 <slaweq> I would especially want to ask db experts (looking at You njohnston :)) to look at https://bugs.launchpad.net/neutron/+bug/1831009
14:28:23 <openstack> Launchpad bug 1831009 in neutron "Improper close connection to database leading to mysql/mariadb block connection." [Undecided,New]
14:29:16 <mlavalle> is this reported against master branch?
14:29:37 <mlavalle> oh, I see he is reporting the neutron version
14:29:42 <slaweq> no, it's Neutron-server: openstack-neutron-13.0.2-1.el7.noarch
14:30:36 <mlavalle> that's rocky
14:30:44 <slaweq> yes, I think so :)
14:31:49 <slaweq> we also have 2 bugs related to api performance: https://bugs.launchpad.net/neutron/+bug/1830679 and https://bugs.launchpad.net/neutron/+bug/1830630
14:31:51 <openstack> Launchpad bug 1830679 in neutron "Security groups RBAC cause a major performance degradation" [High,New]
14:31:52 <openstack> Launchpad bug 1830630 in neutron "Get external networks too slowly because it would join subnet and rbac" [Medium,New]
14:32:08 <slaweq> both are not assigned so would be good if someone would have time to take a look
14:32:54 <slaweq> any other bugs You want to talk about today?
14:34:08 <slaweq> ok, I get it as no :)
14:34:17 <slaweq> this week our bug deputy is haleyb
14:34:23 * mlavalle will try to take a look at some of the bugs mentioned above ^^^^
14:34:35 <slaweq> and next week it will be manjeets
14:34:45 <haleyb> slaweq: thanks for the reminder
14:35:00 <slaweq> mlavalle: will You contact manjeets or should I ask him if he will be able to do it?
14:35:04 <slaweq> haleyb: yw :)
14:35:26 <mlavalle> slaweq: go ahead and ping him, please
14:35:33 <slaweq> sure, I will do
14:35:54 <slaweq> ok, next topic then
14:35:56 <slaweq> #topic neutron-lib
14:36:00 <slaweq> boden: hi :)
14:36:02 <boden> hi
14:36:31 <boden> there's a neutron-lib release patch out for review https://review.opendev.org/#/c/661839/   as far as I'm concerned it's good to go
14:37:01 * mlavalle just +1ed it
14:37:02 <boden> would be nice to get that out as I think some folks are waiting for it
14:37:04 <boden> ok thanks!
14:37:26 <mlavalle> yeah prometheanfire was very vocal last week
14:37:38 <boden> the other topic is in regards to reviews for non-neutron networking projects (sfc, l2gw, etc.)
14:37:50 <boden> wondering if we can look to expand the +2 powers in some of these
14:37:56 <boden> perhaps the neutron core team
14:38:19 <slaweq> boden: that was added to "on demand" section :)
14:38:23 <slaweq> but we can talk about it now
14:38:35 <slaweq> thx for bringing this up
14:39:20 <lajoskatona> boden, mlavalle, slaweq: that was discussed during ptg as well, and with mlavalle we planned to have a meeting with l2gw ptl
14:39:21 <mlavalle> is this for neutron-lib consumption patches?
14:39:36 <liuyulong> I have a question, we have decided to use neutron-lib master branch for neutron CI, or not?
14:39:53 <boden> mlavalle yes and no... in general its not easy to land patches in some gates due to lack of reviews.. these could be neutron-lib related or not
14:40:50 <slaweq> yes, I agree with boden here
14:41:02 <mlavalle> do me a favor. Send me an email with the list of projects
14:41:24 <mlavalle> and I'll make sure all the core team members have +2 rights in them
14:41:34 <slaweq> sometimes we have some "trivial" changes e.g. related to jobs definitions or some "mechanical" patches in stadium projects and there is no many people who can +2 those patches
14:42:13 <boden> mlavalle cool thanks
14:42:22 <boden> liuyulong we never got anywhere on that discussion
14:42:23 <slaweq> mlavalle: IMHO all stadium projects should be in this list
14:42:29 <bcafarel> sounds good, recent example is the rehoming of tempest plugins
14:42:42 <mlavalle> I will also start a personal routines to go over the pending patches in those projects
14:42:54 <mlavalle> yeah, but it's more than stadium
14:43:29 <mlavalle> lajoskatona: yes, I will ping ricardo today
14:43:50 <lajoskatona> mlavalle: thanks,
14:44:13 <lajoskatona> mlavalle: otherwise the idea to add +2 right for cores is good.
14:44:27 <lajoskatona> I mean for stadium projects
14:44:56 <boden> we can start with stadium I guess and go from there... if other projects crop up we can discuss expanding +2 rights I suppose
14:45:08 <njohnston> I think you can just include the neutron-cores group in the list of cores for each of the stadium projects... IIRC that is how the stable cores work for stadium projects (at least fwaas)
14:45:13 <amotoki> in my understanding, neutron-release team members have an appripriate right for stadium projects, but it is not true for third-party prijects.
14:45:30 <mlavalle> sounds good boden
14:45:45 <boden> nothing else from me... just business as usual
14:45:58 <slaweq> ok, thx boden for updates
14:46:40 <slaweq> anything else regarding neutron-lib?
14:46:51 <slaweq> or we can move on?
14:47:01 <boden> nothing from me
14:47:19 <slaweq> ok, lets move on then
14:47:23 <slaweq> last topic
14:47:33 <slaweq> #topic On demand agenda
14:47:47 <slaweq> we already discussed one of things from the list
14:47:53 <slaweq> there is also one from njohnston
14:47:58 <slaweq> "Cleaning old OVO compatibility code."
14:48:02 <slaweq> go on njohnston
14:48:11 <njohnston> oh, I think we talked about that last week; my apologies for not cleaning it off the agenda
14:48:21 <slaweq> njohnston: no problem :)
14:48:33 <slaweq> so I will clean it today to not forget next time
14:48:39 <mlavalle> thanks
14:48:51 <slaweq> anything else You want to talk about today?
14:49:07 <slaweq> if not, I will give You couple of minutes back :)
14:49:07 <mlavalle> I don't have anything else
14:49:17 <liuyulong> Hold on
14:49:46 <amotoki> I have nothing special. I still thinks njohnston's topic is worth checked by everyone https://review.opendev.org/#/c/661995/
14:50:07 <liuyulong> One minute about that neutron-lib dev
14:50:21 <tidwellr> njohnston: I owe you an update on https://review.opendev.org/#/c/661995/
14:50:47 <njohnston> thanks amotoki and tidwellr for great feedback on that
14:51:23 <njohnston> the change is to define a policy as regards OVO object compatibility code in such a way that we respect the upgrade windows for distributions; please take a look and let us know what you thing
14:51:25 <njohnston> *think
14:51:52 <tidwellr> njohnston: I can add this to the review, but as long as we suport N->N+2 or greater I think that will be acceptable
14:52:13 <amotoki> njohnston: you're welcome. thanks for leading this coordination :)
14:52:14 <liuyulong> Everytime if neutron touch a constant or a utils function, we will try to move it to neutron-lib, and then neutron dev was blocked by such procedure.
14:52:46 <liuyulong> So it neutron CI does not run on master neutron-lib, this will happen again.
14:52:52 <slaweq> liuyulong: we aren't blocked but a bit slowered down I would say :)
14:53:14 <amotoki> liuyulong: it is true if it affects other stadium projects other than neturon. is my understanding right?
14:53:55 <liuyulong> amotoki, not exactly, event a constant is only used by neutron itself.
14:54:00 <boden> at one point we were discussing something like that topic here https://review.opendev.org/#/c/602748/.  but no one really had any interest
14:55:08 <boden> there are pros and cons to using neutron-lib master vs. released... if someone wants to kick the tires on this topic again go ahead, but I probably don't have the bandwidth
14:55:15 <mlavalle> liuyulong: if a constant or function is used only by neutron, it doesn't have to be sent to the lib
14:55:19 <liuyulong> So, I'd like to say, if we should ensure neutron happy first, then do that move.
14:55:21 <amotoki> liuyulong: if the neutron repo is an only consumer of some constant, there is no need for neutron-lib in pricinpal.
14:55:38 <boden> ^ true
14:55:42 <mlavalle> amotoki is right
14:56:09 <mlavalle> in fact, if that util function or constant is only used by neutron, it shouldn't go to the lib
14:56:23 <liuyulong> Yes, agress
14:56:25 <boden> yep, that was the idea
14:56:26 <liuyulong> agree
14:57:27 <amotoki> API definitions are exceptions as we would like to define the neutron API as a whole of the neutron stadium. All others are to share something in stadium projects.
14:58:42 <liuyulong> However, if a function is only used by neutron alone temporarily, IMO, it should implement in neutron first.
14:59:16 <amotoki> liuyulong: you'ree right
14:59:17 <slaweq> ok, we are running out of time here
14:59:25 <slaweq> thx for attending
14:59:29 <njohnston> o/
14:59:32 <bcafarel> o/
14:59:33 <davidsha> o/
14:59:35 <slaweq> and have a great week!
14:59:36 <slaweq> o/
14:59:38 <slaweq> #endmeeting