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