22:01:49 <armax> #startmeeting neutron_drivers
22:01:50 <openstack> Meeting started Thu May 19 22:01:49 2016 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:54 <openstack> The meeting name has been set to 'neutron_drivers'
22:02:02 <HenryG> o/
22:03:05 <armax> I hope you guys have had time this week to go through our backlog of RFEs and specs
22:03:29 <dougwig> bring it on
22:03:54 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe&orderby=datecreated&start=0
22:04:08 <armax> from last week we have only a handful of new entries
22:04:18 * carl_baldwin walks in a little late.
22:04:52 <armax> bug #1372441
22:04:53 <openstack> bug 1372441 in neutron "[RFE] Creating port in dual-stack network requires IPv4 and IPv6 addresses to be allocated" [Wishlist,Triaged] https://launchpad.net/bugs/1372441 - Assigned to Sean M. Collins (scollins)
22:05:37 <dougwig> maybe it's me, but that seems like "working as intended".
22:05:49 <HenryG> Do we need to discuss this here? The discussion seems to be in the bug comments.
22:05:50 <dougwig> if you don't want to two addresses, make a single stack network?
22:05:52 <carl_baldwin> I remember discussing at the summit a bit and I think I was leaning toward the same conclusion.
22:06:24 <armax> this is true only until one of the subnets runs out of space
22:06:59 <armax> in which case the user is required to be explicitely create a port by specifying the subnet that did not exhaust
22:07:25 <dougwig> isn't that a configuration error?
22:07:39 <carl_baldwin> I still think the expectation on a dual-stack network will be to get addresses in both families.
22:07:40 <armax> dougwig: what do you mean?
22:07:45 <dougwig> as in, it's an odd band-aid when you don't plan your subnets correctly.
22:07:55 <amotoki> i think it is usual that ipv4 and ipv6 subnets have different size of ip addr ranges.
22:08:41 <armax> dougwig: though no-one can anticipate how popular your application becomes and how widely you need to scale out your webfarm
22:08:42 <kevinbenton> Yeah, I think silently giving some VMs only v6 addresses isnt a great user experience
22:08:50 <dougwig> ok, so i'm a user.   i expect both, i get one, with no indication it's an error. how do i fix it?
22:09:07 <armax> dougwig: right now you get an error
22:09:20 * ihrachys wonders how we'll explain inconsistent behaviour when running consequent requests.
22:09:20 <dougwig> right, i agree with the current behavior for that reason.
22:09:30 <ihrachys> sorry, consequent -> parallel
22:10:06 <armax> dougwig: the idea is that the user would have to specify what type of behavior they’d want
22:10:27 <ihrachys> like in: I checked one address is still avail in all subnets; I request a port; due to other user requesting a port just before me, I get a port that I don't expect, with no error indication
22:10:33 <kevinbenton> armax: can't they do that by explicit subnet requests in fixed ups?
22:10:48 <dougwig> armax: so many toggles.  i already have one... i can go make a different network.
22:11:01 <amotoki> kevinbenton: they can.
22:11:03 <armax> kevinbenton: yes, it’s a shortcut
22:11:09 <armax> dougwig: that’s sensible feedback
22:11:21 <amuller> Do we have any indication that this issue is common enough to solve? I'm inclined to ignore it.
22:11:32 <armax> if we agree that we have enough primitives to address the use case with some boilerplate outside neutron
22:11:35 <armax> then I am ok with that
22:12:07 <armax> the use case was aiming at providing some API sugar to simplify the user workflow in some corner case circumstances
22:12:34 <armax> and I sense from this feedback so far that the general sentiment is ‘meh'
22:12:52 <kevinbenton> armax: Yeah, it only would save a step of getting the subnet id
22:12:58 <carl_baldwin> That about sums it up.
22:13:00 <dougwig> i'm a tad into 'actively aganst'.
22:13:05 <dougwig> against.
22:13:07 <dougwig> sigh.
22:13:13 <armax> great, I’ll provide this feeback and kill the RFE
22:13:19 <armax> let’s move on
22:13:25 <amotoki> I am okay with either
22:13:40 <amotoki> we can achieve the reuqest in other way
22:13:49 <armax> bug #1552680
22:13:51 <openstack> bug 1552680 in neutron "[RFE] Add support for DLM" [Wishlist,Triaged] https://launchpad.net/bugs/1552680 - Assigned to John Schwarz (jschwarz)
22:13:52 <armax> any update?
22:13:57 <amuller> none yet
22:14:04 <armax> ok
22:14:05 <armax> moving on
22:14:14 <armax> bug 1563967
22:14:16 <openstack> bug 1563967 in neutron "[RFE] Extend l2-extensions-api for flow management " [Wishlist,Triaged] https://launchpad.net/bugs/1563967 - Assigned to Miguel Angel Ajo (mangelajo)
22:14:43 <armax> this is clearly a continuation of blueprint l2-api-extensions
22:14:44 <ihrachys> on the general idea - we definitely need it.
22:14:52 <ihrachys> especially as we move more stuff to flows
22:15:12 <armax> the devil is in the details…we need to agree on scope and strategy
22:15:16 <ihrachys> this is not an easy task to say the least though
22:15:20 <armax> at least for Newton
22:15:48 <amuller> I think it's pretty easy to justify the need... neutron-server has a robust plugin system, the OVS agent is not there yet
22:16:01 <amuller> with more and more new projects and features using the OVS agent, we need a plugin system
22:16:16 <armax> ack
22:16:34 <armax> let’s move the design discussion on gerrit then
22:16:42 <amuller> I just want to see SFC not fork the OVS agent
22:16:43 <ihrachys> should we move it to spec?
22:16:46 <dougwig> agree, this one is too complicated for this meeting.
22:16:57 <armax> ihrachys: right now ajo_ is working on it as devref
22:17:05 <armax> amuller: ditto
22:17:13 <amotoki> devref sounds good
22:17:14 <armax> amuller: being saying this since vancouver
22:17:36 <amuller> armax: vancouver is a location not a time
22:17:41 * amuller leaves
22:17:51 <dougwig> container flavor chaining, here we come.
22:17:55 * armax takes drivers and core rights away from amuller
22:18:00 * amuller understands
22:18:08 <armax> ok moving on
22:18:13 <armax> bug #1566191
22:18:14 <openstack> bug 1566191 in neutron "[RFE] Allow multiple networks with FIP range to be associated with Tenant router" [Wishlist,Triaged] https://launchpad.net/bugs/1566191
22:18:27 <carl_baldwin> There is a review up now.
22:18:28 <armax> I went through this some more after last meeting
22:18:32 <armax> carl_baldwin: which one?
22:18:35 <carl_baldwin> #link https://review.openstack.org/#/c/292318/
22:18:50 <armax> oh right
22:18:57 <carl_baldwin> The approach, I think, is as you suggested.
22:19:08 <carl_baldwin> If this is the way to go, I don't think we need an RFE.
22:19:11 <armax> carl_baldwin: I didn’t particularly like the use of a class attribute to control behavior
22:19:22 <armax> carl_baldwin: I commented earlier today
22:19:28 <carl_baldwin> armax: I didn't either.  Hence my -1
22:19:33 <armax> carl_baldwin: attaboy
22:20:03 <carl_baldwin> armax: I didn't see your comment.  On the patch set?
22:20:08 <armax> I suppose we can work out how to address the regression and have more breathing room to figure out whetehr we want to evolve the existing model
22:20:14 <armax> carl_baldwin: no on the bug report
22:20:19 <armax> carl_baldwin: but I did reference the patch
22:20:31 <armax> we reached the same conclusions from two different angles
22:20:34 <carl_baldwin> Oh, I missed that update.
22:20:37 <carl_baldwin> :)
22:20:42 <armax> it was only like an hour ago
22:21:52 <armax> once this is resolved we can revise the RFE proposal to better express what is asked
22:22:03 <carl_baldwin> ok
22:22:17 <armax> which, from what I understand, is the desire to allow router uplinking to external networks via router interfaces rather than gateway interfaces
22:22:23 <armax> carl_baldwin: am I right?
22:22:28 <carl_baldwin> armax: Yes, exactly.
22:23:01 <armax> carl_baldwin: I am more concenred with the side effects that something like this may expose
22:23:11 <armax> rather than the API change itself
22:23:26 <armax> anyhow, we’ll continue to iterate on the RFE
22:23:35 <armax> other thoughts? amuller, kevinbenton, anyone else?
22:23:53 <carl_baldwin> If we unblock them by restoring the old behavior, we can think longer on the ultimate solution.
22:23:54 <dougwig> i agree that it seems like a useful enhancement.  and fraught with peril.
22:24:03 <amotoki> it sounds reasonable.
22:24:14 <carl_baldwin> I'm in no rush.
22:24:34 <armax> ok
22:24:39 <armax> bug #1573843
22:24:41 <openstack> bug 1573843 in neutron "[rfe] Minimize agent state reports handling on server side" [Wishlist,Triaged] https://launchpad.net/bugs/1573843 - Assigned to Oleg Bondarev (obondarev)
22:24:42 <amotoki> router:external flag has two meaning: default route and FIP pool. it looks okay to allow FIP pool for router interface too, but i haven't figured out potential concern.
22:25:05 <armax> amotoki: agreed
22:25:30 <armax> this bug from obondarev seems to be borderline between an rfe and a regular fix
22:25:33 <armax> I mean bug
22:25:39 <armax> enhancement if you will
22:26:19 <HenryG> well I guess it affects the RPC api?
22:26:39 <kevinbenton> i don't think this is necessarily about payload size
22:26:43 <armax> HenryG: maybe, it’s not clear if he intends to introduce new RPC calls
22:26:54 <armax> to distirbute the payload and thus minimizing it
22:26:56 <amuller> right, this is about how the server processes report_state
22:27:02 <kevinbenton> it's about having the server understand which data should be handled
22:27:06 <amuller> it's a real problem for the reference implementation, always have been
22:27:09 <kevinbenton> in the context of a normal update
22:27:15 <amuller> I think a patch is a better medium for discussion though
22:27:18 <amuller> cause it's all in the details
22:27:27 <amuller> I don't know if there's anything to discuss at the conceptual level?
22:27:29 <armax> amuller: agreed
22:27:46 <dougwig> i'd say rfe-approved, then move it to gerrit
22:27:57 <armax> sure
22:28:00 <kevinbenton> +1
22:28:08 <HenryG> sounds good to me
22:28:14 <carl_baldwin> ++
22:28:15 <armax> I am not sure this is RFE material though, it seems a genuine optmiziation required
22:28:25 <kevinbenton> (push notifications won't get ride of state reports FWIW)
22:28:36 <kevinbenton> rid*
22:28:44 <armax> but either way we’d need to iterate and see what the code looks like
22:28:50 <armax> moving on
22:28:59 <armax> bug #1577488
22:29:01 <openstack> bug 1577488 in neutron "[RFE]"Fast exit" for compute node egress flows when using DVR" [Wishlist,Triaged] https://launchpad.net/bugs/1577488
22:29:27 <armax> I gave this some thought after last week
22:29:39 <armax> I must admit the diagrams were not very helpful for me
22:30:21 <armax> lack of labelling left too much to the imagination
22:30:26 <armax> and I am not a creative person
22:31:03 <dougwig> so, dvr does north-south at compute node for fip, and not generate nat.  and this rfe doesnt' change that, it just specifies "the operator can do north/south" with vm ip's directly addressable.  isn't that use case covered by provider nets?
22:31:05 <kevinbenton> so i think basically of enable_snat is false we should always fast exit
22:31:07 <armax> having said that I wanted to better understand tidwellr’s comment on enable_snat inability to fit the need
22:31:11 <kevinbenton> if*
22:31:15 <dougwig> /generate nat/general nat/
22:31:23 <armax> carl_baldwin: maybe you can chime in if tidwellr is unable to jump in here?
22:31:38 <kevinbenton> the hesitation around not enabling fast exit with enable_snat =False automatically is asymmetric routing
22:31:38 * tidwellr is lurking
22:31:44 <armax> tidwellr: hi
22:31:50 * carl_baldwin soaking in the feedback.
22:32:07 <kevinbenton> but IMO asymmetric fast exit is better than non-fast exit
22:32:11 <armax> I’d like to understand why you think that enable_snat flag on the router is not fit for the purpuse
22:32:19 <armax> tidwellr: this can be hidden to tenant via policy
22:32:34 <armax> afaik
22:32:53 <tidwellr> that was feedback I got from someone (can't remember who) in Austin
22:33:00 <armax> https://github.com/openstack/neutron/blob/master/etc/policy.json#L100
22:33:08 <armax> and today it’s admin only
22:33:16 <armax> already
22:33:26 <armax> tidwellr: can’t remember who is not acceptable
22:33:32 <armax> we need SSN and banking details
22:33:36 <tidwellr> enable_snat was the first place I went to
22:33:56 <carl_baldwin> I think the question is, is asymmetric routing ok.
22:34:25 <armax> carl_baldwin: within Neutron or in general?
22:34:29 <kevinbenton> i would like to argue that it is
22:34:32 <tidwellr> if you don't want asymmetic routing, use BGP or similar tool
22:34:32 <kevinbenton> armax: with Neutron
22:34:38 <armax> carl_baldwin: because asymetric routing has its own use cases
22:34:47 <carl_baldwin> armax: Not in general.
22:34:56 <armax> carl_baldwin: right, that’s what I am saying
22:34:58 <armax> :)
22:35:22 <kevinbenton> Problem statement: if we fast-exit without the upstream routing knowing how to send back, the return traffic will go through the central node
22:35:46 <tidwellr> kevinbenton: not necessarily
22:36:04 <tidwellr> upstream needs to know to send it back to the central node
22:36:16 <tidwellr> that's not a given
22:36:29 <kevinbenton> tidwellr: that's the use case for enable_snat=False and address scopes
22:36:33 <carl_baldwin> So, we could adjust kevin's statement a little.  "with upstream routing knowing how to send it back symmetrically"
22:36:46 <kevinbenton> tidwellr: if you haven't met that criteria, this discussion is irrelevant because you can't even use non fast-exit
22:36:57 <carl_baldwin> If there is no reason to conntrack in the router, then maybe it is fine.
22:37:05 <tidwellr> kevinbenton: fair enough
22:37:30 <carl_baldwin> There is no NAT so we know we don't need conntrack for that.
22:38:19 <armax> imo we’d need to identify what the implications are of asym routing the way it’s advocated in this RFE
22:38:53 <carl_baldwin> DVR does asymmetric e/w routing all the time.
22:38:58 <armax> perhaps this mode won’t work in conjunction with other services in a Neutron deployment
22:39:40 <tidwellr> I think it's sort of irrelevant if we have a way to track whether there is dynamic routing over an external network
22:40:27 <tidwellr> if we know there is a routing process operating on an external network, we can turn on fast-exit under the covers, otherwise centralize by sending through the SNAT node
22:40:32 <carl_baldwin> tidwellr: But, we could break this in to two steps.  First, enable fast exit optimistically.  Second, try and make it smarter by knowing when there's routing.
22:40:46 <tidwellr> carl_baldwin: true
22:40:48 <kevinbenton> tidwellr: not necessarily. fast-exit could still be desirable even without dynamic routing
22:41:00 <kevinbenton> it fully distributes outbound traffic
22:41:05 <armax> ok but the other question is, is the enable_snat knob given to operator enough to address this need?
22:41:57 <armax> and whether there’s more modeling required to expose this logically to operators when using DVR only
22:41:58 <kevinbenton> armax: i think that comes down to the question of do we need the knob to prevent asymmetric routing
22:42:04 <carl_baldwin> armax: + address scope awareness.
22:43:04 <kevinbenton> carl_baldwin: right, this isn't being directly controlled by enable_snat. it's just whenever the router decides it doesn't need to do SNAT
22:43:17 <carl_baldwin> right
22:43:21 <tidwellr> good point
22:44:05 <armax> kevinbenton: when using DVR in conjunction with enable_snat=False, seems to me that the expection is that asym routing is a given, no?
22:44:34 <kevinbenton> armax: well not ATM. right now it goes through the central node which you presumably have a route pointing at for return traffic upstream
22:44:58 <armax> kevinbenton: well, that would have to change to accommodate tidwellr’s use case
22:45:26 <kevinbenton> armax: yes, that's what he's proposing changing
22:45:32 <armax> because at that point you no longer need to stricly do that
22:45:48 <kevinbenton> armax: well you need something telling upstream where to send traffic to you
22:46:05 <kevinbenton> armax: so in BGP case it can be specific enough that asymmetric doesn't happen
22:46:09 <armax> kevinbenton: but that would need to happen in conjunction with bgp
22:46:27 <kevinbenton> armax: but in a single static route case like 'enable_snat=False' now, it will result in asymmetric routing
22:46:49 <armax> kevinbenton: right, but asym routing is not a problem in itself
22:47:08 <amotoki> is there any problem if we start from asynmetric routing?
22:47:15 <armax> unless there are services that depend on the symmetry of the flow
22:47:20 <kevinbenton> armax: correct
22:47:44 <kevinbenton> amotoki: not that i'm aware of
22:47:45 <armax> thing is, what about something like fwaas?
22:47:47 * armax ducks
22:47:51 <tidwellr> fwiw my thinking was to allow asym routing, then enhance BGP to give you symmetric data flow
22:48:01 <kevinbenton> tidwellr: +1
22:48:21 <tidwellr> BGP will give asym data flow in its current state
22:49:02 <armax> alternatively the asym property can be a property of a dvr router
22:49:07 <kevinbenton> (we can even install routes on the central node pointing to the compute nodes for each internal IP via the external DVR IP of the compute node which will have the central node generate ICMP redirects)
22:49:12 <amotoki> combo of DVR and FWaaS alreday has a problem on async route, so i think this does not bring a new problem.
22:49:52 <armax> and thus can be controlled on a per-router basis, but I like tidwellr’s idea of leveraging the mechanics of BGP to be explicit on the nature of the packet flow
22:49:53 <kevinbenton> so if an upstream router honors ICMP redirects then we would eliminate asymmetric
22:50:50 <kevinbenton> let's move on. i think we've generally settled on 'assume asymmetric for DVR'
22:50:55 <armax> tidwellr: my feedback would be to try and enable this usecase without API changes :)
22:51:30 * carl_baldwin already gave that feedback strongly. :)
22:51:45 <armax> carl_baldwin: great minds think alike
22:51:46 * tidwellr heard loud and clear
22:52:18 <armax> having said that though, I don’t want to hinder tidwellr’s ability to address thsi use case
22:52:42 <armax> but to me it sounds the conversation started on the wrong assumption that enable_snat wasn’t fit for the purpose
22:52:44 <carl_baldwin> I think we could start with the fast exit optimistically approach.
22:52:55 <armax> so we may want to go back on that premise and revise the whole thing
22:53:08 <armax> we in agreement?
22:53:10 <carl_baldwin> So, the router does fast exit any time it would not be doing snat.
22:53:16 <carl_baldwin> I think so.
22:53:17 <kevinbenton> carl_baldwin: +1
22:53:49 <armax> so we implicitly assume asym routing unless something else like BGP will rectify the situation?
22:54:00 <kevinbenton> aye
22:54:05 <carl_baldwin> ++
22:54:07 <armax> okeydokey
22:54:08 <armax> bug #1580588
22:54:10 <openstack> bug 1580588 in neutron "[RFE] use network's dns_domain to generate dns_assignment" [Wishlist,Triaged] https://launchpad.net/bugs/1580588 - Assigned to Miguel Lavalle (minsel)
22:54:41 <armax> anyone cares to elaborate?
22:54:41 <carl_baldwin> So, this was a request to use the dns_domain on the network in dnsmasq as the domain.
22:54:46 <armax> I must admit I did not see this one
22:55:11 <carl_baldwin> Currently, dnsmasq uses the configured domain from neutron.conf, I think.
22:55:34 <amotoki> my understanding is same
22:55:44 <carl_baldwin> I actually thought we were going to do this when dns_domain was added to the network.   But, that isn't how it was done.
22:56:05 <ihrachys> how is dns_domain currently used? [is it?]
22:56:45 <amotoki> it is used for integration with external DNS.
22:56:48 <carl_baldwin> ihrachys: It is used to match up with a domain in designate.
22:57:14 <amotoki> if a port is created, <hostname>.<dns_name in network> is added to designate.
22:57:36 <carl_baldwin> ^ What amotoki said
22:57:39 <ihrachys> I see. so in designate, we don't register a record in zone defined in neutron.conf
22:57:57 <mlavalle> correct
22:58:41 <mlavalle> the zones used for designate come from network's dns_domain attribute
22:59:29 <amotoki> external dns (desginate) has <host>.<dns_name in network> and internal dns (dnsmasq) has <host>.<dns_name from neutorn.conf> for a same IP addr.
22:59:36 <armax> we got one minute left
22:59:43 <carl_baldwin> 20 seconds...
22:59:43 <armax> do we take this offline
22:59:51 <kevinbenton> Ya
23:00:01 <kevinbenton> We need to figure out if we change behavior
23:00:11 <ihrachys> long term we probably want to get rid of the configuration option in neutron.conf. but it's not clear how to do it, since existing users may rely on that domain being used for dnsmasq. maybe an option for dhcp agent to enable usage of dns_domain? and then switch it on later?
23:00:14 <armax> #endmeeting