22:01:18 <armax> #startmeeting neutron_drivers
22:01:19 <openstack> Meeting started Thu May 12 22:01:18 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:22 <openstack> The meeting name has been set to 'neutron_drivers'
22:01:33 <armax> welcome back to our long ‘vacation'
22:01:42 <armax> to->after
22:02:07 <armax> we are back at full speed I support
22:02:35 * njohnsto_ is on from his phone
22:02:43 <armax> njohnsto_: hi
22:02:56 <armax> let’s get back to chewing up at the triaged list of rfe bugs
22:03:05 <njohnsto_> Armax: hello!
22:03:12 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe&orderby=datecreated&start=0
22:03:29 <armax> during past meetings we agreed to skip the bgp ones
22:03:50 <armax> assuming that carl_baldwin et al would get them to resolution
22:04:08 <blogan> o/
22:04:30 <carl_baldwin> still working on them.
22:04:35 <armax> carl_baldwin: did you guys have any chance to sit out and run through the list to see which ones are sensible to tackle in the Newton timeframe?
22:04:38 <armax> carl_baldwin: ok
22:04:57 <carl_baldwin> mostly focused on split
22:05:32 <armax> carl_baldwin: ok, let’s take this offline, I am happy to help where I can
22:05:44 * carl_baldwin thinks the bgp rfes are multiplying
22:05:58 <HenryG> Why is bug 1537971 in triaged state targetted for M-3?
22:06:00 <openstack> bug 1537971 in neutron "[RFE] Add timestamp to neutron resources" [Wishlist,Triaged] https://launchpad.net/bugs/1537971 - Assigned to zhaobo (zhaobo6)
22:06:05 <armax> carl_baldwin: no
22:06:11 <armax> carl_baldwin: there’s 7 as usual :)
22:06:16 <armax> carl_baldwin: I am keeping count :)
22:06:46 <armax> HenryG: a snafus
22:07:06 <HenryG> armax: ok
22:07:18 <armax> but this should be released, so I’ll look into it
22:07:39 <armax> bug 1530331
22:07:39 <openstack> bug 1530331 in neutron "[RFE] [ipv6] Advertise tenant prefixes from router to outside" [Wishlist,Triaged] https://launchpad.net/bugs/1530331
22:08:18 <carl_baldwin> Not much activity on this one.
22:09:16 <armax> carl_baldwin: you were waiting for submitter feedback?
22:09:51 <armax> it seems this is not going anywhere
22:10:32 <carl_baldwin> So, we'd set something on an external network to say that routers should advertise.  And then the routers have to see that and emit router advertisements for the internal networks.
22:10:41 <armax> do we punt it until we have more IPv6 adoption?
22:10:54 <carl_baldwin> I'm okay with that.
22:10:57 <HenryG> +1
22:11:10 <HenryG> We don't know the demand for it yet
22:11:33 <armax> ok
22:11:45 <armax> let’s freeze it for now
22:11:53 <armax> bug 1552680
22:11:54 <openstack> bug 1552680 in neutron "[RFE] Add support for DLM" [Wishlist,Triaged] https://launchpad.net/bugs/1552680 - Assigned to John Schwarz (jschwarz)
22:12:15 <armax> at the summit it was agreed we’d experiment a little to see how beneficial this model is
22:12:34 <armax> amuller, kevinbenton: do I recall correctly?
22:12:52 <amuller> correct, jschwarz has an action item to do some benchmarking
22:13:06 <armax> it may turn out that we’d never gonna take this if experiments are not fruitful
22:13:18 <amuller> let's see what he comes up with :)
22:13:53 <armax> we could turn this RFE into an actual bug report to track what John is working on
22:14:30 <armax> I would like to see the results of his effort recorded somewhere
22:14:38 <amuller> of course
22:14:43 <armax> any idea on how he intended to do that? blog, wiki, devref?
22:15:18 <HenryG> (please devref)
22:15:29 <armax> I guess we’ll keep this RFE on standby
22:15:36 <amuller> I think he was focusing on the content and not the medium
22:16:06 <armax> the medium may end up influencing the content a bit, but I hear you
22:16:20 <armax> what if we said we want to use tweeter?
22:16:31 <armax> he’s stuck with 160 chars at the time
22:16:35 <armax> anyhow
22:16:47 <armax> I look forward to hearing more about this
22:17:09 <amuller> As do I
22:17:21 <armax> bug 1566191
22:17:23 <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:17:51 <carl_baldwin> So, midonet wants this.
22:18:21 <carl_baldwin> Until recently, the API would allow connecting a router internal port to an external network with floating ips.
22:18:40 <carl_baldwin> And, you could assign floating ips from it to ports on other networks.
22:18:56 <carl_baldwin> But, this never worked with the reference implementation and the API loophole was closed.
22:19:11 <armax> um
22:19:41 <carl_baldwin> armax: that's not much of a comment.
22:20:14 <carl_baldwin> would you mind expanding on that?
22:20:16 <armax> carl_baldwin: I am looking that the patch that closed the loophole
22:20:48 <armax> carl_baldwin: in theory could we revert If054945eab058c7138aabbb22cda15890ccb502c?
22:20:50 <kevinbenton> carl_baldwin: so if their tenant routers are attaching internal interfaces directly to the network, doesn't that mean that the tenants had direct access to the network
22:22:27 <armax> and fix it differently?
22:22:27 <carl_baldwin> kevinbenton: I'm not following.
22:22:43 <kevinbenton> why would you need to allocate a floating IP from a network you have direct access to?
22:23:24 <kevinbenton> or can you attach a regular router interface to a 'router:external' network?
22:24:02 <carl_baldwin> kevinbenton: I think they could attach an internal interface to a router:external network.
22:24:16 <carl_baldwin> kevinbenton: I asked that question in the bug report but didn't get a clear answer.
22:24:50 <dougwig> this meeting has been entirely too businesslike and cordial today.
22:24:50 <kevinbenton> carl_baldwin: i see
22:24:58 <carl_baldwin> But, presumably, they needed NAT to communicate with the network.
22:25:13 <kevinbenton> which is what the floating IP would be for i suppose
22:25:20 <carl_baldwin> right
22:25:51 <carl_baldwin> armax: differently how?  Do you have another suggestion?
22:26:43 <armax> carl_baldwin: I am not sure I understand how the API lookhope was closed
22:26:48 <carl_baldwin> I was thinking that connecting a router port that's not the gateway to an external network would be new functionality that might need to be discoverable.
22:27:28 <armax> carl_baldwin: though I don’t quite understand how this might have broken midonet
22:27:29 <kevinbenton> armax: on floating IP associations it looks specifically for gateway ports now to find which router is responisble
22:27:41 <carl_baldwin> armax: The patch made it so that a floating ip had to go through the gateway interface.
22:27:55 <carl_baldwin> ... not just any old interface.
22:28:06 <armax> right, we could perhaps figure out a way to extra the logic in a way that midonet that overload to their liking
22:28:16 <armax> *extract
22:28:22 <kevinbenton> carl_baldwin: this might not need to be restricted to gateway interfaces
22:28:39 <kevinbenton> carl_baldwin: the bug this was solving was to find the correct router
22:28:48 <carl_baldwin> kevinbenton: I don't think it should.  But, if we open it up, will the reference implementation work right?
22:28:51 <kevinbenton> carl_baldwin: we could widen it to also search regular router interfaces
22:29:14 <armax> let
22:29:14 <carl_baldwin> kevinbenton: Yes.
22:29:15 <kevinbenton> carl_baldwin: if not, we can have the reference implementation bail with an error
22:30:00 <armax> let’s discuss strategies on how to tackle this offline
22:30:01 <carl_baldwin> Should we treat this as new functionality that should be discoverable through the API?
22:30:19 <kevinbenton> carl_baldwin: possibly.
22:30:21 <kevinbenton> armax: ack
22:30:41 <armax> I see two approach: one we revert the behavior as it was and we make it possible for different implementations to behave differently
22:30:45 <carl_baldwin> We can move on.  That's my only question ^
22:30:52 <armax> it’s not ideal, but it’s one possibility
22:31:02 <kevinbenton> armax: well that revert fixed another bug
22:31:10 <kevinbenton> armax: so we can't just revert
22:31:28 <armax> kevinbenton: revert to take a different route, but yes
22:31:31 <carl_baldwin> ++
22:31:45 <kevinbenton> ok, next topic! :)
22:31:55 <armax> the other is, as carl_baldwin suggested is to figure out a way to expose this to the user
22:31:56 <armax> ok
22:31:59 <carl_baldwin> Let's continue on the bug.
22:32:05 <armax> moving on, more brainstorming needed
22:32:27 <armax> bug 1577488
22:32:28 <openstack> bug 1577488 in neutron "[RFE]"Fast exit" for compute node egress flows when using DVR" [Wishlist,Triaged] https://launchpad.net/bugs/1577488
22:33:45 <carl_baldwin> Here, the idea is that when we have a routing protocol with host routes for DVR and internal ports, we need DVR to route egress traffic from the port straight to the external network instead of to the network node.
22:34:27 <armax> this does not involve FIP though, right?
22:34:35 <carl_baldwin> armax: right
22:35:26 <armax> so this RFE is about direct connectivity to fixed ip traffic if I understood correctly
22:35:28 <kevinbenton> so for this i think enable_snat or membership to same address scope should inform the agent to skip redirect to central node
22:35:47 <kevinbenton> -1 for yet another config mode on the agent
22:35:49 <carl_baldwin> kevinbenton: Yep, that's the first part.
22:36:01 <carl_baldwin> kevinbenton: I already essentially -2d that.
22:36:13 <carl_baldwin> ... at least in discussions with Ryan.
22:36:19 <amuller> carl_baldwin: the new l3_agent mode?
22:36:34 <carl_baldwin> amuller: -2 to that!
22:36:39 <amuller> ok
22:37:01 <carl_baldwin> My thought was to have a simple way for BGP to register with Neutron as a routing provider.  Then neutron asks it if routing is enabled for the path.
22:37:39 <carl_baldwin> We just need a way to match the egress path with the ingress path.
22:38:04 <carl_baldwin> That seems to indicate asking the routing provider if there is direct routing.
22:38:08 <carl_baldwin> Other thoughts?
22:38:41 <armax> I am wondering what the exact network topology looks like
22:38:43 <kevinbenton> so if we just separate the two, you will get asymmetric routing
22:38:58 <amuller> armax +1
22:39:02 <armax> because this sounds to me like another flavors of provider networks
22:39:05 <kevinbenton> if we fast_exit on the compute node but upstream still sends everything back to the central node
22:39:05 <amuller> the RFE could really use a diagram
22:39:17 <armax> *flavor
22:39:22 <kevinbenton> carl_baldwin: right?
22:39:23 <carl_baldwin> kevinbenton: you're on the right track.
22:40:13 <carl_baldwin> armax: I'm not getting the flavors idea for this.
22:40:43 <carl_baldwin> I'm sure we can whip up some diagrams.  Want to try again later?
22:40:47 <armax> I’ll expand on the bug, but I wonder if we’d end up conflating two different modes of operations
22:41:17 <kevinbenton> ok, let's discuss more later then
22:41:25 <carl_baldwin> ok
22:41:31 <armax> bug 1580239
22:41:33 <openstack> bug 1580239 in neutron "[RFE] Add agent extension framework for L3 agent" [Wishlist,Triaged] https://launchpad.net/bugs/1580239 - Assigned to Nate Johnston (nate-johnston)
22:42:16 <carl_baldwin> So, this one is about creating something to allow FWaaS to register as an extension with the L3 agent.
22:42:17 <SridarK> armax: some background : With the merge of #link https://review.openstack.org/#/c/223343/ - removing the albeit ugly inheritance model with FWaaS - the FWaaS repo is broken. We are looking for an alternate clean model to do this - as none exist today - the RFE was filed.
22:42:22 <armax> I think the devil is in the detals
22:42:23 <njohnsto_> So since FWaaS code is out of L3 agent, the idea is to build a plugin system for L3 agent similar to L2 agent
22:42:28 <carl_baldwin> This one came up because of my patch that broke FWaaS.
22:42:38 <armax> in the sense that I am sure everyone agrees with the intent
22:42:55 <armax> it’s a matter of figuring how on to best achieve the intent
22:43:10 <armax> so this sounds it needs a spec to allow us to iterate and brainstorm on gerrit
22:43:21 <njohnsto_> Armax: agreed totally
22:43:23 <carl_baldwin> armax: +1
22:43:27 <SridarK> armax: +1
22:43:33 <kevinbenton> yeah, i think this is ok. we just need to argue about how it will be done
22:43:38 <armax> a little was already done back in Liberty
22:43:55 <SridarK> armax: we will also need a quick path fwd as fwaas repo is broken now
22:43:59 <carl_baldwin> armax: I showed njohnsto_ what was done then with callbacks.
22:43:59 <armax> with the callback registry to decouple some bits and pieces but definitely more needs to be done
22:44:28 <SridarK> carl_baldwin: with the callback registry i think we can get notifications on router events
22:44:38 <amuller> SridarK: you prolly a different solution to 'fwaas is broken'
22:44:39 <armax> SridarK: you’re not advocating to fix the existing model that assumes that rules are applied at the router level?
22:44:46 <amuller> need*
22:45:28 <SridarK> armax: yes we are on that path we just need a cleaner model to be a part of L3Agent
22:45:32 <carl_baldwin> I think we're talking about two different kinds of broken.
22:46:02 <SridarK> amuller: broken in the sense that the repo is broken and nothing can merge until we get past this
22:46:09 <armax> SridarK: so I would suggest to focus on the relationship that the l3 agent needs to have with fwaas
22:46:12 <armax> in the new model
22:46:20 <SridarK> armax: yes that is correct
22:46:23 <amuller> SridarK: yeah, if the repo is broken I don't think the fix should wait for a spec to be discussed to death
22:46:37 <armax> we can resolve by skipping broken tests :)
22:46:52 <armax> or are we wildly broken?
22:47:01 <njohnsto_> That would be all of the unit tests
22:47:10 <armax> like broken broken? I thought only a bunch of them were not passing
22:47:11 <njohnsto_> Yes we are wildly broken ATM
22:47:11 <armax> ic
22:47:19 <SridarK> i probab am skating on very thin ice if i ask for a revert of 223343 ?
22:47:42 <SridarK> yes basically there is no FWaaS agent now as we are out of L3Agent
22:47:43 <armax> but that’d set you back to a place you don’t wanna be
22:47:59 <armax> so I may be asking a silly question
22:48:19 <SridarK> armax: if we can remove the ugly inheritance once we have a model in place for Services to be part of L3Agent
22:48:32 <armax> but do we know how in the new model how FWaaS is supposed to interact with the L3 agent?
22:48:34 <SridarK> basically after we address this RFE
22:49:07 <armax> because L3 agent handles routers, if rules are applied at port level, I’d almost argue that FWaaS needs to talk to the L2 agent
22:49:10 <SridarK> armax: in the new model on L3 ports it will essentially apply rules on qr interfaces
22:49:41 <SridarK> armax: and on L2 ports there is a part that will be functionality in L2Agent
22:49:42 * carl_baldwin thinks SridarK and armax have *very* different ideas of what "new model" means.
22:50:02 <SridarK> the new model is on ports (both L3 and L2)
22:50:23 <armax> SridarK: ok, understood, I think it should be possible to break the tie altogether
22:50:39 <armax> I see no reason why in the new model the fwaas agent needs to inherit from the L3 agent
22:51:10 <SridarK> armax: that is fine - we will need access to the router ns on fw CRUD operations done thru the agent
22:51:35 <armax> ack
22:51:40 <carl_baldwin> armax: The fwaas inheriting from L3 agent isn't up for discussion afaic
22:51:47 <armax> carl_baldwin: ok
22:52:15 <armax> what I am saying is that I don’t see a need for the short term plan which would entail a revert
22:52:25 <SridarK> carl_baldwin: armax: yes agreed - not long term - my plea was more for the immediate term until we flush out the new relationship with L3Agent
22:52:44 <amuller> armax: you're OK with the fwaas being completely broken for a couple of weeks?
22:52:54 <amuller> fwaas repo*
22:53:07 <armax> but what would you need to merge in the meantime if the end result is gonna look drastically different?
22:53:34 <kevinbenton> armax: well the repo is unusable to make changes
22:53:44 <SridarK> armax: we are in a bit of chicken and egg as we cannot really work thru existing changes
22:53:46 <carl_baldwin> We discussed breaking the inheritance in Paris and nothing was ever done to do it gracefully.  I'm not keen on reverting 223343.
22:53:48 <kevinbenton> armax: are you saying to just shut off all of the tests?
22:53:51 <armax> the fact that we need a v2 makes fwaas unusable
22:53:52 <dougwig> if we don't revert it, you could make a neutron WIP change that was the revert, and make fwaas work that isn't related to that particular bit Depends-On that, and get your jobs working again.
22:54:08 <kevinbenton> dougwig: but they can never merge that way
22:54:43 <dougwig> not until the inheritance issue is resolved, no.
22:54:43 <armax> what I am  saying is that it should be possible to work on a patch that would change the existing architecture and as a result would fix the tests
22:54:56 <armax> surely this means we can merge any changes that affect the server side for fwaas
22:55:14 <armax> so the question is: how long do you guys think that this agent side fix can be done?
22:55:21 <SridarK> armax: yes that can be worked on for sure - the first patch to merge will have to fix this
22:55:43 <SridarK> armax: we are trying to figure this out - but will need help from the L3 team
22:56:05 <armax> I am not opposed to the revert, all I am saying is that I am not sure the revert is gonna buy anything
22:56:16 <armax> SridarK: let me look into the failures
22:56:27 <armax> but the RFE has definitely legs IMO
22:56:50 <SridarK> armax: ok the UT failures showing up are vendor stuff but the basic guts of fwaas is broken
22:56:53 <armax> do you have a bug tracking the UT failures?
22:57:07 <njohnsto_> armax: We can send you what we found about the errors
22:57:14 <SridarK> armax: not yet will open one and link that to the RFE
22:57:26 <armax> was ever the intention of preseving fwaas v1?
22:57:57 <SridarK> armax: it seemed in discussions over M cycle it was felt there could some users so we decided to leave it alone for now
22:58:17 <armax> they can use Mitaka
22:58:26 <armax> :)
22:58:40 <armax> but I hear you
22:58:46 <SridarK> armax: ok we can may be discuss more offline too as we nearing the end
22:58:49 <SridarK> armax: thx
22:58:54 <armax> I suppose that if we want to keep the two approaches work side by side
22:58:59 <armax> that’s a lot more involved
22:59:04 <carl_baldwin> Building on dougwig 's thoughts.  Could fwaas repo use mitaka for tests?
22:59:27 <armax> carl_baldwin: they could pin to stable/mitaka in their requirements file
22:59:34 <armax> but I would cringe at the idea
22:59:49 <SridarK> carl_baldwin: hmm - yes ^^^ armax this may be the only thing that could work
22:59:51 <dougwig> that sounds like madness, since it gets shoved into the guts of neutron-server.  conflicting requirements.txt files
23:00:02 <armax> dougwig: indeed
23:00:10 <SridarK> +1
23:00:18 <armax> ok, we’re at time, thanks we’ll continue offline
23:00:20 <armax> #endmeeting