14:00:06 <mlavalle> #startmeeting networking
14:00:07 <openstack> Meeting started Tue Oct  9 14:00:06 2018 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:10 <openstack> The meeting name has been set to 'networking'
14:00:18 <mlavalle> Hi there!
14:00:45 <hongbin> o/
14:00:46 <lajoskatona> Hi
14:00:52 <tidwellr> hi
14:00:54 <longkb> hi o/
14:01:03 <boden> howdy
14:01:28 <rubasov> o/
14:01:55 <njohnston> o/
14:02:06 <slaweq> hi
14:02:17 <amotoki> o/
14:02:22 <haleyb> hi
14:03:03 <mlavalle> ok, let's get going
14:03:09 <annp_> hi
14:03:17 <mlavalle> #topic Annoucements
14:04:00 <mlavalle> We are a little less of two weeks away from the Stein-1 milestone, October 22 - 26
14:04:48 <mlavalle> Last week week I proposed the addition of bcafarel to the stable branches core team: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135343.html
14:05:14 <bcafarel> o/
14:05:14 <njohnston> +1
14:05:21 <mlavalle> Today marks one week of that nomination, with only positive feedback
14:05:39 <mlavalle> so he should have +2 powers in stable branches any time now
14:05:40 <annp_> +1
14:05:55 <mlavalle> bcafarel: THanks for stepping up to the plate!
14:06:30 <amotoki> I sometimes review stable branches but have less crossing with bcafarel so far.... thanks for stepping up
14:06:45 <amotoki> *in stable reviews
14:06:54 <bcafarel> thanks mlavalle amotoki, I will keep up with your expectations
14:07:29 <mlavalle> Finally, yesterday the Neutron performance team held its first biweekly meeting:
14:07:36 <mlavalle> #link  http://eavesdrop.openstack.org/meetings/neutron_performance/2018/neutron_performance.2018-10-08-16.00.log.html
14:08:14 <njohnston> d'oh!  Sorry I missed it - was off on holiday.
14:08:19 <mlavalle> it takes place every two weeks at 1600 UTC. everybody is invited to chip in
14:08:25 * haleyb missed it too
14:08:52 <mlavalle> any other announcements to share with the team?
14:08:56 <amotoki> re: the stable branches, I would like to discuss a new stable/ocata release before EM in the open discussion section of this meeting.
14:10:26 <mlavalle> amotoki: great, haleyb and I had a chat about that a few days ago. We were waiting for bcafarel to join the team
14:10:46 <mlavalle> very timely!
14:10:55 <mlavalle> #topic Blueprints
14:11:13 <mlavalle> These are the blueprints we are targeting for Stein-1:
14:11:20 <mlavalle> #link https://launchpad.net/neutron/+milestone/stein-1
14:11:44 <mlavalle> Does anybody have any blueprints updates?
14:13:10 <mlavalle> I have a couple of quick updates
14:13:42 <mlavalle> First, last Friday the drivers team approved this rfe: https://bugs.launchpad.net/neutron/+bug/1794771
14:13:42 <openstack> Launchpad bug 1794771 in neutron "SRIOV trunk port - multiple vlans on same VF" [Wishlist,Triaged]
14:14:06 <mlavalle> I am going to create a blueprint for it, so we can track the effort in our weekly meeting
14:14:44 <mlavalle> I also started this past weekend implementing https://bugs.launchpad.net/neutron/+bug/1777627
14:14:44 <openstack> Launchpad bug 1777627 in neutron "RFE: QoS – rule's management (set,delete, show…) requires <qos-policy> parameter in addition to <rule-id>" [Wishlist,In progress] - Assigned to Miguel Lavalle (minsel)
14:15:02 <mlavalle> Here's the first patch: https://review.openstack.org/#/c/608473/
14:15:11 <mlavalle> I will also create a blueprint for it
14:15:49 <amotoki> I resumed mine (policy-in-code) today. last week was too busy week to catch up many internal stuffs during my late summer vacation.... and this Monday was a holiday here. I will post an updated version tomorrow. Thank you all for the review comments
14:16:09 <mlavalle> bcafarel: the drivers also approved this past Friday https://bugs.launchpad.net/neutron/+bug/1789592
14:16:09 <openstack> Launchpad bug 1789592 in neutron "[RFE] Add native OVSDB implementation for OvsdbMonitor" [Wishlist,Triaged]
14:16:21 <mlavalle> do you plan to implement it?
14:16:28 <njohnston> I have a few patches in-flight for bulk port operations, I hope to get new PSes up today to address comments
14:16:43 <bcafarel> I saw it in last meeting summary yes
14:16:56 <mlavalle> bcafarel: ok, great
14:17:09 <bcafarel> mlavalle: I plan to work on it, but if anyone wants to take it, I do not mind :)
14:17:19 <mlavalle> amotoki, njohnston thanks for the updates
14:17:21 <tidwellr> I have https://review.openstack.org/#/c/608357 which migrates neutron-dynamic-routing from Ryu to os-ken
14:17:39 <mlavalle> tidwellr: ah nice!
14:17:54 <mlavalle> that's a good exercise
14:18:14 <mlavalle> Thanks!
14:18:21 <amotoki> nice, but don't we need to coordinate the timing to switch from ryu to os-ken in the neutron stadium?
14:18:45 <mlavalle> amotoki: let's talk about that in the os-ken section
14:18:51 <amotoki> sure
14:19:17 <mlavalle> any toher updates?
14:19:35 <mlavalle> other^^^
14:19:54 <mlavalle> ok, let's move on
14:20:04 <mlavalle> #topic Community goals
14:20:23 * mlavalle notes that amotoki already updated on policy in code
14:20:53 <slaweq> I started working on update check with noop check first
14:20:55 <slaweq> https://review.openstack.org/#/c/608444/
14:21:18 <slaweq> basically it's working, only problem is that new lib oslo_upgradecheck is not released in stable version yet
14:21:46 <mlavalle> nice, great progress!
14:21:57 <mlavalle> thanks
14:22:04 <slaweq> when this will be done, we can add some real checks to it
14:22:23 <slaweq> but community goal is to have this tool with at least noop check, so should be good :)
14:22:33 <amotoki> until stable release, we might use the latest commit by specifying the oslo repo in required-projects in zuul.yaml.
14:22:59 <slaweq> amotoki: yes, but still it fails on requirements check as it's not in openstack/requirements yet
14:23:25 <slaweq> I sent email about that on the weekend and mriedem adviced me to wait a bit for release of this lib
14:23:42 <slaweq> so I think we have some time still and can wait
14:24:04 <njohnston> Looking at the zuul job definitions it looks like it is not going to be too difficult to move all of our zuul jobs to python 3; just need to make sure that the USE_PYTHON3 variable is true in most cases.  That is something that should be easy to add to the .zuul.yaml file.
14:24:08 <mlavalle> so, essentially, we are ahead of the game, great!
14:24:52 <amotoki> njohnston: yeah, it is true for devstack related jobs
14:25:01 <mlavalle> thanks njohnston
14:25:08 <njohnston> But in the process of talking about that in the neutron CI meeting, it came up that our governance standards also direct us to test on whatever the most recent LTS release is as of the start of the cycle; for Stein this is ubuntu Bionic.  Bionic is already being tested by the openstack-tox-py36 job, since it ships with python3.6, so that objective can be achieved by changing the nodeset fo rthe zuul jobs to "ubuntu-bion
14:25:08 <njohnston> ic".
14:25:42 <mlavalle> ok, let's move on
14:26:06 <mlavalle> #topic Starter Approved RFEs
14:26:38 <mlavalle> I want to point out that we have a couple of approved RFEs that are considered low hanging fruit for new contributors:
14:27:06 <mlavalle> https://bugs.launchpad.net/neutron/+bug/1745192
14:27:06 <openstack> Launchpad bug 1745192 in neutron "Can't create a vlan transparent network in mixed driver environment" [Wishlist,Confirmed] - Assigned to Pawel Rusak (rusakp)
14:27:27 <mlavalle> This one one taken over back in June, but I didn't see any progress all summer lomng
14:27:49 <mlavalle> slaweq: did rusakp reach out to you again?
14:28:02 <slaweq> mlavalle: not in last few months
14:28:26 <mlavalle> ok, let's hold for a couple of weeks. if we don't see any progress, we can un-assign it
14:28:59 <mlavalle> also this past Friday the drivers approved: https://bugs.launchpad.net/neutron/+bug/1792901
14:28:59 <openstack> Launchpad bug 1792901 in neutron "[RFE] subnet pool can not delete prefixes" [Wishlist,Triaged]
14:29:14 <mlavalle> it's unassigned and tidwellr has offered to provide guidance
14:29:55 <tidwellr> do we need someone to jump in and finish this off?
14:30:26 <mlavalle> not in a hurry. do you want it?
14:30:29 <tidwellr> I'm happy to take a look
14:30:41 <mlavalle> feel free
14:31:11 <tidwellr> alrighty then
14:31:15 <mlavalle> bcafarel: we can also advertise in this section: https://bugs.launchpad.net/neutron/+bug/1789592
14:31:15 <openstack> Launchpad bug 1789592 in neutron "[RFE] Add native OVSDB implementation for OvsdbMonitor" [Wishlist,Triaged]
14:31:33 <mlavalle> for a few weeks. If nobody shows up, you can implement it
14:32:23 <mlavalle> ok, let's move on
14:32:28 <mlavalle> #topic Bugs
14:32:54 <mlavalle> Last week our deputy was Swami
14:33:04 <mlavalle> I don't see him around though
14:33:13 <mlavalle> and didn't see a summary from him
14:34:38 <mlavalle> This is what was reported over the past few days: https://bugs.launchpad.net/neutron/+bugs?orderby=-datecreated&start=0
14:34:56 <mlavalle> I see a lot of undecided there
14:35:20 <mlavalle> The only critical one is https://bugs.launchpad.net/neutron/+bug/1795870
14:35:20 <openstack> Launchpad bug 1795870 in neutron "Trunk scenario test test_trunk_subport_lifecycle fails from time to time" [High,Confirmed]
14:35:29 <slaweq> mlavalle: some of them are from this week and I didn't check them yet
14:35:35 <slaweq> but I will do it
14:35:50 <mlavalle> slaweq: is this the one I am supposed to take over?^^^^
14:35:56 <mlavalle> you didn't ping me
14:36:05 <slaweq> mlavalle: yes
14:36:09 <slaweq> ahh, I forgot :/
14:36:22 <slaweq> I created bug and forgot to ping You later
14:36:24 <slaweq> sorry
14:36:28 <mlavalle> no problem
14:36:34 <mlavalle> I just assigned it to me
14:36:38 <slaweq> thx mlavalle
14:36:55 <mlavalle> so don't yell at me during the CI meeting ;-)
14:37:36 <mlavalle> ok, any other bugs we should discuss today?
14:37:37 <amotoki> i also have new bug mails last week. I can share efforts to check them.
14:37:47 <slaweq> mlavalle: of course :)
14:38:05 <mlavalle> amotoki: thanks!
14:38:46 <mlavalle> well, as hinted by slaweq earlier, he is our deputy this week
14:38:49 <mlavalle> Thanks!
14:38:52 <slaweq> yep
14:39:01 <slaweq> and this time I remember about that ;)
14:39:07 <mlavalle> LOL
14:39:14 <mlavalle> #topic neutron-lib
14:39:29 <mlavalle> boden: you are up
14:39:32 <boden> hi
14:40:09 <boden> the only real thing I want to mention (again) is that moving forward I'll only be posting neutron-lib consumption patches to those projects who opted in
14:40:33 <boden> here's the topic I was using for those opt-in patches for ref https://review.openstack.org/#/q/topic:neutron-lib-current-optin
14:40:45 <mlavalle> yeap, don't be afraid to remind us constantky
14:41:24 <boden> not much else exciting to mention from me
14:41:32 <mlavalle> good progress!
14:42:13 <mlavalle> sfc is as I expected :-(
14:42:32 <boden> TaaS as well... and they asked about opting in
14:42:38 <boden> guess lack of reviewers
14:42:46 <mlavalle> and with tap as a service, we probably need to enable some people with +2 powers
14:43:15 <mlavalle> I'll talk to munimeha1, since he is actively working on it
14:43:25 <mlavalle> and will loop yamamoto in
14:43:25 <boden> mlavalle if you think that's the right thing to do... my main concern is that this is a testament from the project opting in that they can review the  consumption patches
14:43:36 <boden> but we can see
14:43:46 <boden> you know me... I will complain if things go south ;)
14:43:57 <mlavalle> I know :-)
14:44:23 <mlavalle> anything else here?
14:44:28 <boden> not from me
14:44:36 <amotoki> neutron-lib consumption patches and project activeness are separate things though they are tightly coupled....
14:45:07 <boden> amotoki very tight
14:45:18 <mlavalle> #topic CLI / SDK
14:45:26 <mlavalle> any updates on this topic?
14:45:32 <amotoki> nothing from me this week
14:45:58 <mlavalle> ack
14:46:06 <mlavalle> #topic os-ken
14:46:19 <mlavalle> hongbin: you are up
14:46:26 <hongbin> hi
14:46:38 <hongbin> i want to mention a few things
14:46:55 <hongbin> 1. the storyboard of os-ken is created
14:46:58 <hongbin> #link https://storyboard.openstack.org/#!/project/openstack/os-ken
14:47:17 <hongbin> for os-ken, we will use storyboard to track BPs, bugs, etc.
14:47:34 <hongbin> 2. os-ken 0.1.0 is release
14:47:38 <hongbin> #link https://review.openstack.org/#/c/607010/
14:48:12 <hongbin> this is the initial release of os-ken, the version start with "0" means it is in beta status
14:48:34 <hongbin> 3. i am requesting to add os-ken to the global requirement
14:48:36 <hongbin> #link https://review.openstack.org/#/c/609018/
14:49:02 <hongbin> after that, neutron and stadium project will be able to consume this library and do some initial testing
14:49:15 <hongbin> that is all i want to share, any question for that?
14:49:38 <amotoki> what is the recommended process if we receive bugs in neutron launchpad related to os-ken/ryu?
14:50:42 <hongbin> mlavalle: you have an answer for amotoki 's question?
14:50:54 <mlavalle> the idea is that we track os-ken bugs in storyboard
14:51:17 <mlavalle> so if we receive them in launchpad, we should transfer them to storyboard
14:51:21 <njohnston> I would copy the text into a storyboard story, then mark the LP bug 'invalid' and provide a link to the storyboard story.  I don't know how to reflect critical/high/medium/low/wishlist status in storyboard.
14:51:27 <amotoki> i think the way is to create a new story on storyboard, leave a comment in launchpad and keep it open till it is fixed in os-ken .
14:52:07 <amotoki> per ML discussion, storyboard has no priority mechanism in its design.
14:52:28 <slaweq> amotoki: I don't think we need to keep it open in launchpad until bug is fixed
14:52:57 <mlavalle> I think this is a good approach, amotoki....
14:52:59 <amotoki> slaweq: I think it depends on situations. if it affects neutron behaviors, it is worth opend.
14:53:05 <amotoki> s/opend/opened/
14:53:21 <slaweq> yes, in such case it can
14:53:32 <njohnston> +1
14:53:38 <mlavalle> correct, but in principle, let's close it in Launchpad
14:53:38 <slaweq> should we then link related os-ken patch to this lp bug also?
14:53:54 <mlavalle> slaweq: yes
14:54:00 <slaweq> e.g. as "related-bug", right?
14:54:05 <mlavalle> yes
14:54:08 <slaweq> ok
14:54:11 <amotoki> +1
14:54:37 <mlavalle> actually, I'll add a summary of this discussion to our bugs triaging policy
14:54:37 <slaweq> also please note that You can link patch to story/task from storyboard so we should require that too in such patches for os-ken
14:54:44 <slaweq> (just to mention :))
14:54:50 <mlavalle> we can refine it thorugh your firandly reviews
14:55:05 <mlavalle> friendly reviews^^^
14:55:32 <mlavalle> ok, let's move on
14:55:44 <mlavalle> #topic On demand agenda
14:55:54 <mlavalle> amotoki: let's talk about ocata
14:56:05 <amotoki> the time left is limted. I would like to share our situation.
14:56:13 <amotoki> as you may know, we introduced a new way to maintain stable branches.
14:56:18 <amotoki> It is called as "extended maintenance" (EM).
14:56:24 <amotoki> We won't cut a release after entering to the EM phase.
14:56:47 <amotoki> We have several commits after the last release of stable/ocata.
14:57:13 <amotoki> nova team is thinking to cut a new release for stable/ocata: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135483.html
14:57:27 <amotoki> I think the neutron team is in the same situation.
14:57:40 <mlavalle> that message is what triggered my chat with haleyb
14:57:48 <mlavalle> and yes, we agree
14:57:49 <amotoki> we also have several open stable/ocata patches.
14:58:28 <amotoki> I think it is better to visit pending reviews and then cut a release
14:58:38 <haleyb> we need to merge or abandon, then cut, then go EM
14:58:42 <haleyb> we had the same idea
14:58:59 <amotoki> haleyb: we don't need to abandon open reviews.
14:59:08 <amotoki> because EM does not mean EOL
14:59:40 <haleyb> amotoki: ok, maybe i'm just thinking of some that have been sitting a while
14:59:58 <mlavalle> I think we are more or less in the same page
15:00:19 <mlavalle> we ran out of time
15:00:23 <mlavalle> #endmeeting