14:00:06 <mlavalle> #startmeeting neutron_drivers 14:00:06 <openstack> Meeting started Fri Feb 16 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 'neutron_drivers' 14:00:31 <mlavalle> Good evening! 14:00:36 <mlavalle> Good morning! 14:02:50 <amotoki> Good night! :p 14:02:51 <amotoki> hi 14:03:16 <mlavalle> amotoki: you going to Dublin? 14:03:26 <amotoki> mlavalle: yes 14:03:32 <mlavalle> \o/ 14:03:47 <mlavalle> you joining us for dinner on Thursday? 14:04:10 <amotoki> i haven't checked it yet, but I will go. 14:04:18 <amotoki> I will leave Dublin on Sat morning 14:05:21 <mlavalle> at the top of the etherpad, https://etherpad.openstack.org/p/neutron-ptg-rocky, please add your name. The format is: name (irc handle) days in Dublin yes/no dinner 14:06:21 <mlavalle> This is where we are going for dinner on Thursday: http://thecelt.ie/ 14:06:53 <mlavalle> Thanks :-) 14:11:57 <slaweq> hi 14:12:04 <mlavalle> slaweq: hi 14:12:19 <mlavalle> we are waiting for a third driver to join and have quorum 14:12:27 <mlavalle> so far it's amotoki and me 14:12:36 <slaweq> I though that from what I see :) 14:12:41 <mlavalle> LOL 14:12:44 * haleyb had figured freenode went split brain there was such a long pause 14:13:12 <mlavalle> haleyb: just a few more hours and ...... off to the beach! 14:13:30 <slaweq> lucky You haleyb :) 14:13:45 <haleyb> yes, it's hard to work today, my next work day is Dublin 14:14:00 <mlavalle> you flying tomorrow? 14:14:13 <haleyb> monday morning, but a lot of things this weekend 14:14:22 <mlavalle> ahhh, have fun! 14:14:41 <haleyb> thanks! 14:15:26 <mlavalle> slaweq: while we wait, do you think we should discuss those ECN proposals in Dublin? 14:15:55 <slaweq> IMO this one which reedip proposed is quite clear 14:16:03 <slaweq> but this second one - yes :) 14:16:20 <slaweq> maybe it's worth to talk with author of this proposal 14:16:38 <slaweq> I will not be in Dublin unfortunately 14:17:31 <mlavalle> ok, I'll add a time slot to the agenda to discuss QoS stuff. I'll put that proposal along with another one that Liu Yulong added to the etherpad 14:18:03 <mlavalle> would you help me adding enough comments there so we can have enough context to discuss it in Dublin? 14:18:33 <slaweq> sure, I will try to add my comments to etherpad at the beginning of next week 14:19:07 <mlavalle> slaweq: cool, thanks 14:19:23 <mlavalle> amotoki: let's assume we won't have quorum 14:19:26 <amotoki> slaweq: regarding ECN stuff, I am not sure what kind of ECN support can be exposed as neutron-qos. I 14:19:54 <amotoki> slaweq: previously I commented it in the rfe bug, but perhaps QoS team has a good view on it. 14:21:06 <amotoki> mlavalle: no problem 14:21:18 <slaweq> amotoki: there are 2 proposed RFE related to ECN 14:21:21 <slaweq> https://bugs.launchpad.net/neutron/+bug/1505627 14:21:21 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee) 14:21:48 <slaweq> this one is IMHO clear - neutron can enable ECN on routers/networks 14:22:06 <slaweq> but user will need to enable it inside VMs if he will want to use it 14:22:19 <slaweq> and second one is https://bugs.launchpad.net/neutron/+bug/1708460 14:22:19 <openstack> Launchpad bug 1708460 in neutron " [RFE] Reaction to network congestion for qos" [Wishlist,Triaged] - Assigned to Fouad Benamrane (ftreqah) 14:22:23 <yamamoto> oops, sorry to be late 14:22:40 <mlavalle> yamamoto: welcome 14:22:54 <mlavalle> amotoki: you still around? 14:22:57 <slaweq> which is little bit different as author propose to measure and "react" by setting qos bw limits on ports if it is necessary 14:23:01 <amotoki> yes :) 14:23:47 <mlavalle> amotoki: the author of the second one claims he has PoC code 14:24:00 <mlavalle> didn't he, slawek? 14:24:17 <amotoki> to make ECN support work, we need end-to-end support of ECN including outside of openstack cloud 14:25:01 <slaweq> mlavalle: I don't know about PoC 14:25:09 <mlavalle> slaweq: ok 14:25:30 <mlavalle> amotoki: if you have a chance, please leave a comment in that second RFE. Thanks for your opinion 14:25:43 <amotoki> mlavalle: ack. I wasn 14:25:48 <amotoki> mlavalle: ack. I wasn't aware of the second one 14:25:49 <slaweq> amotoki: I know, so reedip proposed that neutron can enable it on "neutron's stuff" like routers 14:26:39 <mlavalle> ok let's get moving 14:26:59 <mlavalle> First of all, this is our patch for RC2: 14:27:05 <mlavalle> #link https://review.openstack.org/#/c/544749/ 14:27:27 <mlavalle> once we merge that, we will be done with Queens 14:28:08 <mlavalle> This is what we were targeting in that RC2: https://launchpad.net/neutron/+milestone/queens-rc2 14:28:16 <amotoki> dashboard stuffs will be released next week too. 14:28:37 <mlavalle> Thanks for that update 14:29:27 <mlavalle> Moving on to RFEs 14:29:41 <mlavalle> First one we have this morning is: 14:29:49 <mlavalle> https://bugs.launchpad.net/neutron/+bug/1748132 14:29:49 <openstack> Launchpad bug 1748132 in neutron "[RFE] Can not create router gateway without external_fixed_ips" [Low,In progress] - Assigned to Guoshuai Li (liguoshuai1990) 14:31:30 <haleyb> i believe there was a proposed patch 14:32:07 <amotoki> we can see neutron-lib patch https://review.openstack.org/#/c/542106/ 14:32:30 <amotoki> and neutron patch https://review.openstack.org/#/c/540806/ 14:32:44 <mlavalle> ahh nice 14:32:54 <haleyb> i had asked for a bug since it was a behavior/api change 14:33:17 <amotoki> a big change is about the behavior. 14:33:37 <yamamoto> i'd like to see a tempest scenario for features like this 14:33:54 <amotoki> I wonder who requests "no IP address for a gateway port" 14:35:19 <amotoki> it is an improvement as operator side (they can save IP addresses), but from user perspective users do not care it in most cases 14:36:02 <amotoki> if we change the default value, it would be a big change, so I wonder what is the right direction of this rfe. 14:36:52 <mlavalle> so your concern is backwards compatibility? 14:37:00 <haleyb> so this would be no default snat IP? 14:37:06 <amotoki> mlavalle: yes if we change the default value. 14:37:22 <amotoki> haleyb: that's my understandng 14:38:09 <mlavalle> what is the default value now? 14:38:27 <amotoki> the current default behavior is to assign an IP address from an external net. 14:38:53 <mlavalle> ah ok, more than a value, you are referring to the bahavior 14:38:56 <yamamoto> is anyone suggesting to change the default behaviour? i thought it was about providing a way to create a gateway port without ip. 14:39:00 <amotoki> this proposal is to allow to specify no IP address for an external gateway IP. 14:39:34 <amotoki> this works but even after that most users do not specify "no IP address" in most cases. 14:40:02 <amotoki> so my question is how operators can leverage this feature to save their global IP addresses. 14:41:09 <amotoki> I am okay with the current request itself. my question might see too much 14:41:50 <haleyb> they can also use subnet service types today to save global IP addresses 14:42:00 <mlavalle> so, if the user / deployer doesn't use this new api call, the default behavior is the same as currently, right? 14:42:33 <yamamoto> mlavalle: that's my understanding 14:42:38 <amotoki> yes 14:42:56 <amotoki> this rfe just allows to specify [] as external_fixed_ips 14:43:13 <mlavalle> also haleyb's observation is correct 14:43:23 <mlavalle> here's what I propose we do: 14:44:10 <mlavalle> 1) haleyb can suggest in the RFE the use of service subnets to address the use case, i.e. saving publicly available ip address 14:44:33 <mlavalle> if for some reason we discover that doesn't fly, then: 14:44:58 <mlavalle> 2) we indicate in the RFE that the current default behavior should remain 14:45:08 <mlavalle> does that make sense? 14:45:28 <amotoki> totally agree 14:45:37 <haleyb> the one downside to not having an IP is you can't determine if the router is reachable externally, but as long as they understand that's a limitation... 14:45:38 <yamamoto> sounds reasonable 14:45:59 <haleyb> mlavalle: sounds good, i just made more work for myself :) 14:46:06 <haleyb> job security 14:46:14 <mlavalle> haleyb: LOL 14:46:49 <mlavalle> but if I remember correctly, saving public IP addresses is THE service subnets use case, right? 14:46:55 <SotK> I'm sure it will 14:47:04 <SotK> w/w, sorry 14:47:12 <amotoki> mlavalle: yes 14:47:15 <amotoki> even if we use service type subnets, a user cannot get reachable IPs but an operator can check IP reachability. 14:47:38 <haleyb> mlavalle: yes, target was DVR since we have all the routers on compute nodes 14:47:41 <amotoki> the only difference is users will see unreachable IP address (from users) vs no IP address. 14:48:19 <mlavalle> ok, cool, we have a plan for this one 14:48:58 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1690425 14:48:58 <openstack> Launchpad bug 1690425 in neutron "[RFE] neutron cells aware" [Wishlist,Triaged] 14:49:27 <mlavalle> Last time we talked about this one, we agreed that next step is to create a PoC 14:50:00 <mlavalle> the only thinng I want to mention is that I will bring it up during the PTG, to give it visibility and see if we get volunteers 14:50:07 <mlavalle> makes sense? 14:50:12 <amotoki> +1 14:50:31 <yamamoto> +1 14:51:03 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1715386 14:51:03 <openstack> Launchpad bug 1715386 in neutron "[RFE]Support routing traffic based on subnet" [Wishlist,In progress] - Assigned to zhaobo (zhaobo6) 14:51:27 <mlavalle> I see that yamamoto provided feedback in the spec on this one 14:51:37 <mlavalle> I have to go over it again myself 14:52:06 <mlavalle> over the next 4 or 5 days, China is celebratin New Year 14:52:23 <mlavalle> so we won't see a response from Zhaobo 14:52:44 <mlavalle> it may be a good opportunity for me and amotoki to provide feedback in the spec 14:53:08 <mlavalle> any other comments 14:53:12 <mlavalle> ? 14:53:14 <amotoki> yeah, i haven't got a chance to review it. let me try 14:53:32 <mlavalle> cool 14:53:39 <mlavalle> thanks 14:53:42 <yamamoto> i'm still celebrating new year as i still have mochi to eat. 14:53:57 <amotoki> so it seems better to add some comment to the RFE bug itself 14:54:04 <mlavalle> yamamoto: that's the way to go, celebrate all year long. LOL 14:54:19 <mlavalle> amotoki: whichever way you prefer 14:54:58 <amotoki> something like "we are assessing this RFE in the spec proposed" 14:55:09 <mlavalle> ok 14:55:20 <mlavalle> good point amotoki 14:55:49 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1720727 14:55:50 <openstack> Launchpad bug 1720727 in neutron "[RFE] (Operator-only) Add support 'firewall_group' for loggable resource type" [Wishlist,Triaged] 14:57:46 <yamamoto> i guess it's fine to approve as far as fwaas team is ok 14:58:04 <mlavalle> yes, they seem to be ok with it 14:58:24 <mlavalle> any concerns amotoki? 14:58:38 <amotoki> i'm fine to approve it. 14:58:50 <mlavalle> ok, cool, approved it is 14:59:04 <amotoki> the author proposed a spec on this 14:59:11 <amotoki> do we continue to review it? 14:59:26 <amotoki> i think it is good to have 14:59:47 <mlavalle> of course, RFEs are supposed to be a step before the spec 14:59:58 <mlavalle> and the spec is where we flesh it out 15:00:58 <mlavalle> Please remember that this meeting won't take place on Friday March 2nd, as we will be in Dublin attending PTG. Next Friday meeting wil be March 16th 15:01:15 <mlavalle> Thanks for attending 15:01:21 <amotoki> how about the next week? 15:01:21 <mlavalle> #endmeeting