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