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