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