14:00:14 <mlavalle> #startmeeting neutron_drivers
14:00:15 <openstack> Meeting started Fri Mar 16 14:00:14 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:19 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:26 <ihrachys> o/
14:00:37 <mlavalle> hi yamamoto, ihrachys
14:00:45 <mlavalle> Nice to see you!
14:01:35 <mlavalle> Let's get going....
14:01:54 <mlavalle> RFEs for today are here:
14:02:02 <mlavalle> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe-triaged
14:02:35 <mlavalle> First one for today is https://bugs.launchpad.net/neutron/+bug/1748132
14:02:35 <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:03:50 <mlavalle> We had proposed to the submitter use of subnet service types to acomplish the same thing
14:03:55 <amotoki> hi
14:04:08 <mlavalle> amotoki: o/
14:04:55 <mlavalle> Now he clarified that he is using networking-ovn
14:05:20 <mlavalle> haleyb: you around?
14:05:36 <haleyb> yes, i'm here, i was reading the bug again
14:06:37 <haleyb> i don't exactly understand his Question #1
14:06:48 <haleyb> in comment 13
14:07:12 <haleyb> is it just a static route on the upstream router?
14:07:29 <mlavalle> I think it is
14:07:43 <mlavalle> but he seems to have found a solution for 1
14:07:56 <mlavalle> Problem is 2
14:08:07 <amotoki> re #1, in normal linux router case, a next hop does not response and ns router will return icmp unreachable
14:09:07 <haleyb> so with problem 2 it's using default snat if no floating
14:09:19 <mlavalle> right
14:09:44 <mlavalle> and if no fip, he doesn't want traffic to go out
14:10:31 <ihrachys> 2 could be approached as a bug, no? just block it. is there a use case where we would want to leak?
14:11:18 <amotoki> but how can we detect we cannot do SNAT for a case of 2.
14:11:19 <amotoki> ?
14:13:19 <mlavalle> If we come up with a 'signalling' mechanism, we might as well revert to his original proposal
14:14:31 <amotoki> yeah, I think so.
14:14:37 <mlavalle> in other words, Router Gateway Port without IP
14:16:18 <amotoki> another option is a combination of subnet with private IP and no snat attribute. it might save tables resource for SNAT, but it will fall into 1.
14:16:48 <amotoki> perhaps gateway port without IP is easier to understand compared to no SNAT option in this case
14:17:48 <mlavalle> you mean his original proposal?
14:18:00 <amotoki> mlavalle: yes
14:18:23 <mlavalle> Yes, seems the cleaner alternative
14:18:55 <haleyb> mlavalle: there is the enable_snat flag in the external_gateway_info object, i haven't played with it in a while
14:19:45 <mlavalle> We can play with it over the next few days
14:20:10 <amotoki> i mean enable_snat flag by "SNAT" option
14:20:10 <mlavalle> propose him to play with it
14:21:29 <haleyb> https://specs.openstack.org/openstack/neutron-specs/specs/api/configurable_external_gateway_modes.html does say enable_snat is there to change the behavior, and floating ips will work regardless
14:22:12 <yamamoto> he want to make the router not to forward traffic from ip without fip, right?
14:22:23 <yamamoto> with or without snat
14:22:45 <amotoki> yamamoto: yes. he says "VM access to public network through floating IP only."
14:23:07 <mlavalle> and he wants to save the a public ip address
14:23:28 <mlavalle> in the router gateway port
14:24:19 <amotoki> as operator perspective, service subnet will prevent from wasting public IP addresses. from user perspective, no gateway IP is easier to understand.
14:24:34 <yamamoto> with subnet service types, we can save a public ip but can't stop forwarding
14:24:42 <amotoki> i think at least he need to use service type for subnet to save IP addresses.
14:25:09 <mlavalle> right, we can't stop forwarding
14:26:25 <amotoki> his proposal of no gateway IP is just an user option. it seems better to ask him whether he would like to save public IP addrs as system level.
14:27:21 <mlavalle> he already says that in the original rfe: "in order to save public IP network"
14:28:31 <amotoki> yes, perhaps we would like to save IPs as operators
14:29:04 <mlavalle> haleyb: do you propose a combination of subnet service type with enable_snat?
14:30:01 <haleyb> mlavalle: i think that case could work.  but i'm also thinking about amotoki's comment that no gateway IP is easy to understand
14:30:40 <mlavalle> yeah, his original proposal
14:30:54 <haleyb> i hadn't assumed someone would want to disable snat entirely
14:31:05 <mlavalle> I was fine with it originally. seemed reasonable with me
14:31:27 <yamamoto> with enable_snat=false the router would forward those packets without snat. i don't think it's what he wants.
14:32:25 <mlavalle> go back to his original proposal?
14:32:59 <haleyb> yamamoto: they might actually be dropped based on scoping, or dropped in the upstream router, but maybe not in his config
14:33:47 <yamamoto> haleyb: avoiding snat is somehow common for distributed implementations like midonet, where distributing snat state can be expensive.
14:34:36 <haleyb> mlavalle: so maybe the original proposal wins?
14:34:50 <mlavalle> that's my opinion
14:35:00 <mlavalle> what do others think?
14:35:37 <amotoki> I think one minus point of the original proposal is operators cannot enforce no IP for a gateway port.
14:36:04 <amotoki> this is the point I am not clear.
14:36:07 <yamamoto> i'm leaning to the original proposal.  or make enable_snat 3 mode (add "drop" mode)
14:37:36 <yamamoto> amotoki: you mean cloud admin vs tenant admin?
14:37:54 <amotoki> yamamoto: tenant vs admin
14:38:22 <yamamoto> admin wants to save public ips but tenant might not follow the policy?
14:38:51 <amotoki> yamamoto: that's a possible case as having IP for a gateway port is our default
14:39:58 <yamamoto> maybe it can be solved separately with policy.json or something like that?
14:41:08 <amotoki> good point
14:42:01 <mlavalle> That would be beyond the scope of this RFE, right?
14:44:47 <mlavalle> go back to original proposal?
14:44:53 <amotoki> it is a difficult point. at now, the policy framework cannot enforce user to always specify some field, so it means it is not easy to enforce it to users..
14:45:08 <yamamoto> or some kind of quota to motivate tenants to save public ips
14:46:49 <amotoki> honestly this RFE focuses on no IP of a gateway port
14:47:12 <amotoki> and more demand should be a separate topic
14:47:16 <mlavalle> yeap
14:48:24 <mlavalle> My opinion is still towards the original proposal
14:48:34 <yamamoto> +1
14:48:56 <amotoki> +1. how about posting questions/feedbacks based on today's discussion if any?
14:49:16 <mlavalle> yes, I would do that
14:49:34 <mlavalle> ihrachys, haleyb: what do you think?
14:49:37 <amotoki> i will post a point i raised above (tenant vs admin)
14:49:42 <haleyb> +1
14:49:50 <mlavalle> amotoki: agree
14:50:23 <mlavalle> cool
14:50:47 <ihrachys> I don't have a useful thought :)
14:51:44 <mlavalle> ihrachys: that's fine :-)
14:52:24 <mlavalle> fwiw, I didn't expect this lengthy discussion last night when I was preparing for this meeting.... LOL
14:52:42 <amotoki> hehe
14:52:54 <mlavalle> Good discussion, though. Thanks!
14:53:48 <mlavalle> Moving on, next one is https://bugs.launchpad.net/neutron/+bug/1690425
14:53:49 <openstack> Launchpad bug 1690425 in neutron "[RFE] neutron cells aware" [Wishlist,Triaged]
14:54:09 <mlavalle> For this one we want someone to work on a PoC
14:54:29 <mlavalle> What I think I will do is I will create a blueprint for it in Launchpad
14:55:09 <mlavalle> so we can discuss / advertise it in the weekly meeting during the blueprints section
14:55:16 <mlavalle> makes sense?
14:56:26 <mlavalle> In the interest of time, I will take that as a yes ;-)
14:56:41 <mlavalle> Following one is https://bugs.launchpad.net/neutron/+bug/1690425
14:56:42 <openstack> Launchpad bug 1690425 in neutron "[RFE] neutron cells aware" [Wishlist,Triaged]
14:56:42 <amotoki> possible.
14:57:19 <amotoki> same bug?
14:57:27 <mlavalle> sorry
14:57:39 <mlavalle> https://bugs.launchpad.net/neutron/+bug/1715386
14:57:40 <openstack> Launchpad bug 1715386 in neutron "[RFE]Support routing traffic based on subnet" [Wishlist,In progress] - Assigned to zhaobo (zhaobo6)
14:58:07 <mlavalle> For this one, I think we need to go back to the spec and give it a review
14:59:42 <amotoki> same understanding
14:59:52 <mlavalle> and given that we are short of time, next week we can start with https://bugs.launchpad.net/neutron/+bug/1723026
14:59:53 <openstack> Launchpad bug 1723026 in neutron "[RFE]Support get device_ids from floatingips" [Wishlist,Confirmed] - Assigned to Hongbin Lu (hongbin.lu)
15:00:12 <amotoki> Regarding bug 1743480, I still didn't get the point in the RFE. I commented in #19. hopefully you can check it.
15:00:13 <openstack> bug 1743480 in neutron "[RFE] No way to differentiate beween floating IP networks and external provider networks" [Wishlist,Confirmed] https://launchpad.net/bugs/1743480
15:01:16 <mlavalle> sounds good amotoki. thanks
15:01:24 <mlavalle> #endmeeting