22:02:22 #startmeeting neutron_drivers 22:02:23 Meeting started Thu Jun 15 22:02:22 2017 UTC and is due to finish in 60 minutes. The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:02:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:02:26 The meeting name has been set to 'neutron_drivers' 22:03:00 before we go through the list of RFEs, there is one i would like to address right away because the spec is already ready and it's pretty simple 22:03:24 #link https://bugs.launchpad.net/neutron/+bug/1686035 22:03:25 Launchpad bug 1686035 in neutron "[RFE] More detailed reporting of available QoS rules" [Wishlist,Triaged] - Assigned to Slawek Kaplonski (slaweq) 22:03:54 this is an admin-api to disover qos capabilities of the drivers 22:04:25 there is even a patchset already, I believe 22:04:41 ah no, it is the spece 22:05:44 ok. you feel good about adding discoverability just for qos without looking at broader picture? (we may have this kind of request for other backend specific features) 22:05:58 btw I am not saying that's not the right path 22:06:28 just want to make sure that we see how we may need to deal with the extension in the future if/when we implement discoverability for other stuff 22:06:35 ihrachys: yeah, i think a broader capabilities API might be a good long-term goal 22:06:53 ihrachys: but i think with our limited resources we can just do this one and then force a future one to generalize 22:06:59 rather than trying to preemptively do it 22:07:29 yeah I guess we already took enough broad major projects on our plate, so we can't really deliver anything more general in next X cycles :) 22:07:50 so I am fine, it's a needed thing, and if slaweq_ will work on it, I think we can give it a go. 22:08:00 ack 22:08:02 ofc pie in the sky would be better 22:08:08 ++ 22:08:46 hi 22:08:51 yeah, i was just thinking it's hard to envision up front capturing capabilities that aren't clear rule types like this 22:09:10 amotoki, armax: thoughts? 22:09:57 * armax mulls over 22:10:18 yeah, let’s not boil the ocean 22:10:41 that's the right expression, LOL 22:11:02 amotoki: any objection? 22:11:13 armax, yeah, let's leave THIS ocean as-is, we have several others in progress 22:11:25 generally the discoverability like this is helpful. 22:13:12 ok, let's approve and maybe next cycle we can generalize a bit better once things like the enforcement framework rkukura was looking into have taken shape 22:13:21 feature enforcement * 22:14:00 is it still on the radar, the Bob's thing? 22:14:10 haven't heard of it for awhile ;) 22:14:23 ihrachys: i'm not sure. i haven't either. i'll have to sync up with him 22:15:04 ok 22:15:25 #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe 22:15:48 #link https://bugs.launchpad.net/neutron/+bug/1491317 22:15:49 Launchpad bug 1491317 in neutron "[RFE] Add TCP/UDP port forwarding extension to L3" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee) 22:16:16 reedip has already a spec up for review 22:16:38 https://review.openstack.org/470596 22:16:39 patch 470596 - neutron-specs - [WIP] Spec for Port Forwarding 22:17:36 so i'm okay with this if it's done as an extension in the l3 agent 22:17:40 there’s very little detail about how this would work with DVR 22:17:47 or L3 HA 22:18:10 at the time he is only proposing to implement the API 22:18:12 armax: well L3 HA is easy 22:18:18 armax: same as regular 22:18:22 DVR is a problem though 22:18:29 since this does say it applies to floating IPs 22:18:47 my suggestion would be to have any approach to DVR to be stated upfront 22:18:55 the last we need is another broken experience 22:20:12 armax: so what do you suggest for RFE state? Approve it and have the feature depend on all of that being defined in the spec? 22:21:04 if reedip has enough cycles to put the spec in good shape we can approve and work on the spec to make sure we agree on the steps forward 22:21:26 armax: yeah, he reached out to me and said he has time to work on it 22:21:36 I agree, let him develop the spec and that's where we ask all the questions 22:22:07 + 22:22:09 ok, i'll put a note that the RFE is approved but the feature won't make it unless we get a clear DVR integration story in teh spec 22:22:09 we need to define the api behavior well on top of FIP API. +1 for spec. CVR impl including L3-HA will be straight-forward. 22:22:25 well, any routing flavor 22:22:41 I appreciate that HA might be easy, but nothing is really easy about neutron 22:22:58 i think API behavior will be easy to describe from what the expected external behavior is 22:23:07 HA is easy and yet there was quite some work to get it to play well to l2pop 22:23:19 armax: but this won't affect taht stuff 22:23:27 the unexpected nuisance is always around the corner 22:23:30 it's just on the existing floatingip 22:23:33 that’s all I am trying to say 22:23:35 the problem is DVR that i can see 22:23:39 let’s try to think about these upfront 22:23:43 how to get traffic from a compute node to another 22:23:55 It’s need to be discussed that if port-forwarding needed to be applied to router’s external gateway ip? 22:24:17 and only by calling them out in the spec we can get more eyes on it and have more scrutiny 22:24:24 or the spec only focus on floating ips 22:25:01 i think we should probably limit to floating IP to start 22:25:09 external gateway isn't normall visible to users` 22:25:22 once we have floating IPs worked out, then we can consider gateway interfaces 22:25:55 yes, and there may be conflict when there are both snat and port-forwarding on external gateway 22:26:06 external gateway address may be already used by other traffic and it leads to a bit complicated situation. 22:26:11 yeah 22:28:27 #link https://bugs.launchpad.net/neutron/+bug/1649417 22:28:29 Launchpad bug 1649417 in neutron "RFE: Security group rule using address set" [Wishlist,Triaged] - Assigned to Dongcan Ye (hellochosen) 22:28:41 so, this returned to us 22:30:42 yeah 22:30:53 so it sounds like the workarounds work but are hacky 22:30:59 which is sort of what I suspected 22:31:07 we discussed the api one or two meetings ago 22:31:47 we talked about overloading remote id 22:31:55 I just left a question about implementation resources 22:32:00 remote_group_id 22:32:07 it kinda sounds like this is a request with nobody to implement it 22:32:27 let's revisit once we know if we have someone to do the work 22:32:36 sounds good 22:33:06 https://bugs.launchpad.net/neutron/+bug/1653932 is still a TODO item for me 22:33:07 Launchpad bug 1653932 in neutron "[rfe] network router:external field not exported" [Wishlist,Triaged] - Assigned to Kevin Benton (kevinbenton) 22:33:51 #link https://bugs.launchpad.net/neutron/+bug/1667877 22:33:52 Launchpad bug 1667877 in neutron "[RFE] DVR support for Configuring Floatingips in Network Node or in the Compute Node based on Config option." [Wishlist,Triaged] 22:34:22 I am sorry but I can’t help myself but disklike this use case 22:34:47 it adds a layer of complexity that I found difficult to digest 22:35:02 what do you mean you dislike the use case? 22:35:50 you don't understand it? 22:35:54 or you don't want to support it 22:36:00 I have snowflakes 22:36:01 hate 22:36:05 Basically DVR offers two things 22:36:14 direct east/west routing 22:36:15 this sounds like have snowflakes in the DC 22:36:19 and direct north/south routing 22:36:40 * armax loves to be lectured on DVR by kevinbenton 22:36:43 if you want east/west routing, you are forced to adopt the north/south 22:37:07 and the north/south has a big deployment cost of getting the external network to every single compute node 22:37:38 you want the cake and eat it too 22:37:43 on a per-node basis 22:37:54 I think that’s complexity for the sake of it 22:37:56 no 22:38:03 that's an implementation detail 22:38:25 the use case i'm aware of driving this would be okay with it being a whole deployment-level thing 22:38:27 what is the fundamental raltionale to get your external network to only a fraction of your computes? 22:38:31 the second sentence sounds complicated... "Also proactively check the status of the agent on the destination node and if the agent health is down, then configure the Floatingip on the Network Node." 22:38:42 armax: you don't bring your external network to any of your compute nodes 22:38:53 armax: it only goes to a rack of network nodes 22:38:59 this makes the overall solution brittle and prone to weird failure modes that are more difficult to troubleshoot should the platform be homogenous 22:39:38 then use a HA router for N/S and a DVR router for E/W 22:39:59 armax: so you tell tenants they just create two routers in their network? 22:40:05 this mix-and-match approach will spell trouble 22:40:23 first of all, we need to reconsider how we expose the router attribute to the regular tenant 22:40:31 what router attribute? 22:40:47 I am actually having second thoughts that hiding HA and Distributed to end user was a good idea to begin with 22:41:30 armax: what are you talking about? telling a tenant to create two routers and setup routes to point to one for E/W and one for N/S is a terrible solution 22:41:53 armax: it requires tenants to know about infra limitations 22:42:03 right, that’s a niche 22:42:51 can you explain to me what limitation you see in bringing external connectivity to the compute layer? 22:43:13 l3 fabric that can't have VLANs extended across it 22:43:34 if you are saying that you want distributed E/W without distributed DNAT that doesn’t spell out how it’s supposed to be implemented 22:44:32 wouldn’t routed networks solve that? 22:44:57 armax: nope. routed networks doesn't support BGP on external networks yet 22:45:05 right, but once it does? 22:45:38 then if the operator is willing to allow BGP into their network, yes 22:46:03 that sounds like a much cleaner solution to me 22:46:25 no added complexity in neutron’s control plane 22:46:30 ha! 22:46:44 win-win :) 22:46:51 you're joking, right? 22:47:13 how do you think the BGP prefix advertisement setup is going to get information from the server? 22:47:29 that goes via well defined interfaces 22:47:47 you build on top of what you already have rather than ripping things out from whitin 22:47:48 within 22:48:34 so we're going to make this use case dependent on vaporware? 22:48:54 you and I probably won’t reach consensus within 5 of these meetings and we should probably take this offline, but I’d like to hear other people’s opinions 22:49:03 vaporware that would force the operator to adopt BGP nonetheless 22:49:10 no, make the vaporware a reality 22:51:01 the simpler solution in the short term is not necessarily the one that’s gonna pay off in the long run 22:51:20 btw I have no educated opinion hence silence :) 22:51:27 LOL 22:51:42 armax: leave your comments on here https://bugs.launchpad.net/neutron/+bug/1667877 22:51:43 Launchpad bug 1667877 in neutron "[RFE] DVR support for Configuring Floatingips in Network Node or in the Compute Node based on Config option." [Wishlist,Triaged] 22:51:43 ihrachys: I thought you had your hands occupied with popcorns 22:51:49 armax, both 22:51:51 I thought I already had 22:52:14 my opinion of this hasn’t changed, but I’ll reference this nail biting conversation 22:52:16 I can enjoy a good fight without getting into details. fist to the left, punch to the right. 22:52:16 armax: IMO a non-existent more complex feature is a pretty lame answer to this request 22:53:15 kevinbenton: right now I am simply stating that I’d rather this addressed cleanly without a lame configuration toggle that makes the fabric brittle and difficult to troubleshoot 22:53:34 if a cleaner solution involved more work that currently doesn’t exist, so be it 22:53:45 I am tired of promoting hacks over hacks 22:54:04 armax: the 'cleaner' solution is dependent on a project not even tested in the neutron gate 22:54:26 that’s not an excuse to encourage the stop-gap 22:54:43 'stop-gap' is just a term for a solution you don't like 22:54:53 side note: a lot of things we rely on are not tested in gate, that's not a good argument 22:55:23 can we use routed network as an external network for FIP? perhaps no? i think i don't understand the baseline. 22:55:25 ihrachys: for normal neutron traffic operation? 22:55:38 perhaps we can find a different solution that is between a dummy config option and boiling the ocean with BGP 22:55:51 I am simply inviting people to think more carefully 22:55:57 amotoki: armax is suggesting we extend support of routed networks to external networks with the using of the networking-dynamic-routing project 22:56:31 kevinbenton: right now I am simply saying that I hate the proposed solution to the use case presented 22:56:35 amotoki: so the l3 agent in the rack can announce the addresses in that segment 22:56:50 ah i see 22:56:53 I am not 100% sold on the use case, but I guess I can get behind it 22:57:07 amotoki: I think carl had put up a spec about it 22:57:12 and at this point we have an approved rfe, where the next step is to write a spec 22:57:48 mlavalle: i'm not sure we even have it approved though 22:58:03 it sounds like armax does not want to support splitting E/W from N/S in DVR 22:58:37 not according to the proposal made, I suppose I should come up with a counterproposal 22:58:42 sorry 22:58:49 at time i think 22:58:51 i think it is nice if we have a solution not specific to dvr. dvr-specific logic will leads to less folks familiar with that 22:58:57 let me mull over this a bit, it’s not exactly high up on the list of my priorities lately 22:59:03 kevinbenton: https://bugs.launchpad.net/neutron/+bug/1667329 22:59:04 Launchpad bug 1667329 in neutron "[RFE] Floating IP Subnets on Routed Provider Networks" [Wishlist,Triaged] - Assigned to John Davidge (john-davidge) 22:59:32 since John left, the agreement we made in the L3 subteam is to write the spec by the end of this cycle 22:59:36 for which I am terribly sorry 22:59:38 :'( 22:59:39 and implement in the next 23:00:06 time check 23:00:15 kevinbenton ^ 23:00:17 mlavalle: ok. so routed external nets maybe in queens 23:00:24 #endmeeting