14:57:43 <mestery> #startmeeting neutron-drivers
14:57:44 <openstack> Meeting started Tue Sep 29 14:57:43 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:57:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:57:48 <openstack> The meeting name has been set to 'neutron_drivers'
14:57:50 <armax> thanks for stepping in
14:57:55 <mestery> #link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda Agenda
14:57:56 <mestery> armax: Anytime :)
14:58:03 <mestery> #info I'm running this meeting at the behest of our fearless leader armax :)
14:58:06 <armax> I’ll clear my calendar from next week onward
14:58:10 <mestery> armax: ACk
14:58:18 <armax> mestery: ruthless is more appropriate
14:58:24 <mestery> #topic Spec review
14:58:30 <mestery> #undo
14:58:31 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x9990fd0>
14:58:35 <mestery> #topic RFE Bug Review
14:58:57 <mestery> dougwig: https://review.openstack.org/#/c/202797/
14:58:59 <mestery> #link https://review.openstack.org/#/c/202797/
14:59:03 <mestery> dougwig: That needs a re-spin.
14:59:50 <dougwig> you guys started early!
14:59:55 <mestery> #link https://goo.gl/xtBJkU Open RFE bugs
14:59:58 <mestery> dougwig: I know, right? :)
15:00:07 <dougwig> computer is still waking up/loading.
15:00:12 <mestery> dougwig: Ack
15:00:19 * mestery waits and hands kevinbenton some coffee
15:00:20 <kevinbenton> mestery: major fopaux
15:00:36 <kevinbenton> mestery: it's 5 pm where i'm at, no coffee needed
15:00:47 <mestery> kevinbenton: I forget, you're in the land of salv-orlando's!
15:00:47 <kevinbenton> mestery: give mine to dougwig
15:00:55 <mestery> kevinbenton: He likes red bull, not coffee.
15:01:04 <dougwig> i assume we did the pre-topic of making sure armax still wants a drivers team?  :)
15:01:23 <mestery> dougwig: I did that offline :)
15:01:24 <salv-orlando> he might be but this does not mean I'm supposed to be working now
15:01:27 <mestery> But yeah, I think he's ok with it.
15:01:32 <kevinbenton> the drivers team is at risk? quick, make a bunch of rash decisions that cannot be reversed
15:01:34 <dougwig> mestery: ack, will respin rfe and infra devrefs
15:01:35 <mestery> salv-orlando: Isn't it happy hour where you are?
15:01:40 <mestery> dougwig: Coolio!
15:02:08 * carl_baldwin wanders in
15:02:18 <mestery> OK
15:02:25 <mestery> Lets look at the link here: https://goo.gl/xtBJkU
15:02:30 <mestery> 23 bugs in that list
15:02:34 <mestery> However
15:02:37 <mestery> Lets take a pause
15:02:47 <mestery> I think we need to do a post mortem on this RFE process
15:02:52 <dougwig> yikes
15:02:55 <mestery> What do others think?
15:03:34 <dougwig> it's fine, if we review regularly. i liked -specs better, just because the tooling is better around queueing my workflow, but... eh.
15:03:45 <mestery> dougwig: Ack on all of that
15:03:54 <kevinbenton> i liked the lightweightness of the rfe
15:04:00 <mestery> kevinbenton: ++
15:04:03 <kevinbenton> just having it in launchpad made it easy to forget about
15:04:08 <mestery> yup
15:04:18 <carl_baldwin> ++
15:04:28 <dougwig> +1
15:04:35 <mestery> OK, lets discuss with armax to get his viewpoints later as well. Lets move forward with RFE review!
15:04:37 <mestery> I'll link them here
15:04:42 <mestery> And we can discuss one at a time. Sound good?
15:04:47 <kevinbenton> sgtm
15:05:19 <mestery> First up
15:05:27 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1475792
15:05:27 <openstack> Launchpad bug 1475792 in neutron "Change Neutron so that it can auto-allocate networks" [High,Confirmed] - Assigned to Brian Haley (brian-haley)
15:05:27 <mestery> "Get Me a Network" now
15:05:28 <dougwig> i thought the first was the get me a network api.  either auto-select or auto-allocate, if it's unambiguous.
15:05:55 <mestery> I'm going to mark it triaged so work can begin.
15:05:56 <mestery> Anyone disagree?
15:06:15 <carl_baldwin> agree
15:06:16 <kevinbenton> i'm +1 for this one, that port scheduler thing i suggested would be a big component of this
15:06:28 <kevinbenton> might be worth collapsing it into this
15:06:47 <mestery> kevinbenton: Ack, for now, Triaged, lets collapse at a future date.
15:06:48 <mestery> Up next
15:07:03 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1370033
15:07:03 <openstack> Launchpad bug 1370033 in neutron "Admin should be able to manually select the active instance of a HA router" [Low,Confirmed] - Assigned to yong sheng gong (gongysh)
15:08:02 <dougwig> that's a useful sanity mechanism in a prod environment.
15:08:02 <mestery> Looks like this one needs API changes
15:08:12 <mestery> But useful for sure, agree with dougwig
15:08:17 <kevinbenton> i'm okay with this one. next step is spec filing then?
15:08:31 <mestery> kevinbenton: Yes, since it requires an API change
15:08:34 <mestery> We'll need a spec.
15:08:36 <dougwig> kevinbenton: only if we need a spec. is it an obvious enough change?
15:08:45 <mestery> dougwig: API changes require specs, right?
15:09:16 <carl_baldwin> A spec with a small API section filled out should do it.  The API change won’t be big.
15:09:55 <mestery> Done
15:09:55 <mestery> Next
15:10:04 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1475717
15:10:04 <openstack> Launchpad bug 1475717 in neutron "RFE: Security Rules should support VRRP protocol" [Wishlist,New] - Assigned to Li Ma (nick-ma-z)
15:10:46 <mestery> Seems simple enough
15:10:58 <dougwig> mestery: i thought we didn't need specs if it was obvious, like adding a boolean field.  rfe + code is pretty explanatory in a case like that.  spec is always fine, though.
15:11:08 <mestery> dougwig: For this one?
15:11:08 <kevinbenton> i'm confused about the comments on that bug
15:11:18 <dougwig> mestery: no, i was one back.
15:11:20 <kevinbenton> it sounds like they found a way to do it without it?
15:11:34 <mestery> dougwig: Right, but for API changes, I think we want it so it gets more review? Maybe I'm wrong.
15:11:39 <dougwig> on the vrrp/sg one, my only question is should we be adding protocols piecemeal, or allow them all?
15:11:50 <amotoki> hi
15:11:54 <dougwig> mestery: just my personal opinion, specs on trivial things are a waste of time, so i'd say no.
15:12:05 <mestery> dougwig: Comment in bug, fine by me, I agree, KISS
15:12:06 <mestery> So
15:12:08 <mestery> For this VRRP one
15:12:25 <mestery> kevinbenton: It does work, it's just more user friendly to include the canonical VRRP name in the dropdown
15:12:26 <mestery> To me, I'd be fine approving this one
15:12:31 <mestery> It's simple and makes things user friendly
15:12:40 <dougwig> do we want to do just vrrp?  what about gre, ipsec, ....?
15:13:08 <kevinbenton> would this even be a change on the server side or just to allow the client to accept the simple names?
15:13:17 <mestery> dougwig: Agreed
15:13:23 <dougwig> or let 'all' pass more than tcp/udp.
15:13:37 <mestery> kevinbenton: https://review.openstack.org/#/c/203173/
15:14:17 <kevinbenton> mestery: i see. i'm thinking we should probably just populate them all in one fell swoop then
15:14:27 <amotoki> at now I don't know it affects ip_protocol or protocol number (perhaps ip proto), but I agree we support more values.
15:14:29 <mestery> kevinbenton: Comment in the bug then?
15:14:35 <kevinbenton> mestery: it's not that much extra work
15:14:40 <kevinbenton> mestery: sure
15:14:41 <salv-orlando> can I point out that since this is expanding the security feature, we need to consider that some bakcends which are not the ref impl might not support that
15:14:47 <salv-orlando> or need to implement support for that
15:14:53 <kevinbenton> salv-orlando: !
15:14:56 <salv-orlando> and that should be dealt with by the mgmt layer
15:15:01 <mestery> salv-orlando: We consider other backends? Since when? ;)
15:15:11 <kevinbenton> salv-orlando: but they would have this issue now
15:15:25 <kevinbenton> salv-orlando: just by using the proto number instead of name, right?
15:15:27 <salv-orlando> mestery: since we have OVN. Before that we did mot give a damm ;)
15:15:32 <mestery> rofl
15:15:46 <mestery> It would seem this isn't as cut and dried as we'd like it to be then
15:15:58 <carl_baldwin> This work is just assigning names to numbers, right?
15:16:06 <salv-orlando> the backend would yes. It's a matter of expectations on the user side. I don't care about backends either.
15:16:18 <mestery> carl_baldwin: Correct
15:16:30 <salv-orlando> If you tell users that VRRP is a valid protocol and then the server returns a nice 500 when you try to specify it, that's not nice
15:16:41 <dougwig> i care about them, but i'm not going to let it stop us from expanding the interface.
15:16:47 <kevinbenton> salv-orlando: do these show up in an API listing somewhere?
15:16:53 <amotoki> dilemma between consistent supported values and backend support....
15:17:21 <salv-orlando> I think it's ok to approve the RFE anyway
15:17:26 <amotoki> If users can know supported values via API, it sounds good.
15:17:49 <salv-orlando> the blueprint is about symbolic names at the end of the day no need to start a bikeshedding session
15:17:51 <kevinbenton> where do these show up? I thought it was just a translation thing
15:18:13 <salv-orlando> we can look at how to deal with unsupported protocols separately. It should be trivial anywya.
15:18:44 <salv-orlando> we can move on I guess. I've already wasted too much of your time.
15:19:09 <salv-orlando> My comment was out of place and I regret having made it.
15:19:09 <mestery> OK
15:19:10 <mestery> Lets move on
15:19:18 <mestery> We've got other sheds to paint this morning/evening
15:19:25 <mestery> salv-orlando: Shame on you ;)
15:19:27 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1457034
15:19:28 <openstack> Launchpad bug 1457034 in neutron "BGPVPN extension" [Undecided,Confirmed]
15:19:53 <salv-orlando> I'm completely dressed in shame. It's the only thing that makes me feel comfortable when I wear it
15:20:04 <mestery> It looks pretty good on you too ;)
15:20:06 <dougwig> no, it wasn't. it delves into the question of if plugins should have an interface to report what they support, so the user gets a sane experience.
15:20:31 <salv-orlando> yeah but it has no bearing on the RFE being discussed
15:20:43 <mestery> That issue has come up before
15:20:54 <dougwig> disagree, but we seem to be arguing the others position.  :)
15:20:58 <vikram__> carl_baldwin: can you please confirm if doesn't collide with the ongoing BGP work
15:21:24 <carl_baldwin> vikram__: We’ve discussed this quite a bit.  I don’t think it collides.
15:21:44 <kevinbenton> dougwig: i think the point is that backends will have unsupported protocols with or without nice names for them
15:21:57 <vikram__> carl_baldwin: ok.. So we don't want to extend the existing BGP work for advertising VPN routes?
15:22:01 <kevinbenton> mestery: is this bringing in the external project?
15:22:19 <carl_baldwin> I did think they were going to do this work externally.
15:22:24 <mestery> kevinbenton: I think this bug may be outdated because they HAVE the external project already
15:22:27 <mestery> I think we can mark it invalid
15:22:30 <kevinbenton> mestery: right
15:22:31 <mestery> And let them tell us otherwise
15:22:37 <kevinbenton> mestery: too the bit bucket!
15:22:40 <kevinbenton> to*
15:22:55 <mestery> next up
15:22:57 <vikram__> carl_baldwin, mestery: thanks.. i felt it's for neutron
15:23:03 <mestery> :)
15:23:06 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1464361
15:23:06 <openstack> Launchpad bug 1464361 in neutron "Support for multiple gateways in Neutron subnets" [Undecided,Confirmed] - Assigned to Shraddha Pandhe (shraddha-pandhe)
15:23:25 <mestery> carl_baldwin: Your eyes here would be good :)
15:23:56 <kevinbenton> this gives me the heebie jeebies
15:24:06 <kevinbenton> it feels like implementation details are being leaked
15:24:14 <kevinbenton> and it's going to be a ton of work
15:24:15 <carl_baldwin> kevinbenton: +1
15:24:32 <carl_baldwin> Part of me wants to say let’s focus on routed networks.
15:24:39 <mestery> carl_baldwin: Well, indeed
15:24:41 <kevinbenton> i think we need a lot more demand from users before pushing this one further
15:25:09 <carl_baldwin> I think this can also be solved with better infrastructure.
15:25:34 <mestery> kevinbenton: Please mark it as "Won't Fix" with that info
15:25:39 <mestery> I think we can agree on that one it appears
15:25:52 <kevinbenton> right, let's revisit after we get routed networks all modeled up
15:25:56 <mestery> ++
15:25:56 <dougwig> err.
15:26:00 <amotoki> agree
15:26:25 * mestery waits a second for dougwig before moving on
15:26:35 <dougwig> i think it fits pretty well with provider networks, which we're pushing hard, but it can wait, i suppose.
15:27:18 <haleyb> and with DVR a second gateway doesn't get you much, without it it might help, or with provider as doug said
15:27:25 <mestery> dougwig: Once it starts talking about load balancing between back planes, that seems like implementation detail leakage to me
15:27:27 <kevinbenton> dougwig: how so? i don't see this in datacenter network designs much
15:28:10 <dougwig> if you use dhcp to pass a gateway that's closer to the vm, you can spread the gateway load out pretty simply (e.g. leaf and spine.)
15:28:12 <kevinbenton> dougwig: just to get same broadcast domain but then have completely different paths out of the network?
15:28:21 <kevinbenton> dougwig: yeah, that is le suck
15:28:22 <kevinbenton> :)
15:28:38 <dougwig> i'm not saying it's how i'd set it up, but if i ended up with a huge ass copper subnet for some reason, i could see using it.
15:29:09 <carl_baldwin> I’d like to see more demand for this still.
15:29:10 <kevinbenton> dougwig: right. i would rather we build on the primitive of same IP is implemented in multiple locations like DVR
15:29:29 <dougwig> (as he types this into a browser that's attached to an asymmetric routed subnet, for reasons i don't even want to begin to get into.)
15:29:36 <mestery> lol
15:29:56 <dougwig> kevinbenton: this isnt' about what makes sense to a greenfield.  this is about how to work with existing network infrastructures, in my mind.
15:30:30 <kevinbenton> dougwig: right, but how would you even know which gateway IP to pick until the VM is scheduled (which is not port creation time)
15:30:40 <kevinbenton> (at least not all of the time)
15:30:49 <dougwig> kevinbenton: i'd run my own dhcp server on the provider net.
15:31:12 <kevinbenton> dougwig: well if you're going to do that, what do you need this feature for?
15:31:28 <dougwig> kevinbenton: because i have a giant copper subnet with multiple gateways that i like?
15:31:47 <dougwig> *loop detected*
15:32:05 <kevinbenton> dougwig: no, i mean what good does having the gateway IPs appear in the API do?
15:32:25 <kevinbenton> dougwig: if you have an external DHCP system that understands how the assignment of IP to gateway will work
15:32:41 <dougwig> oh, true, true.
15:32:52 <dougwig> so this must want neutron to manage that.
15:33:00 <kevinbenton> right
15:33:11 <dougwig> which would need some kind of scheduler affinity that can inform dhcp.  hmm.
15:33:12 <kevinbenton> in which case something needs to understand topology
15:33:27 <kevinbenton> an ML2 driver could conceivably do this
15:33:29 <mestery> Topology, it's always topology at the end of the day
15:33:36 <mestery> There is a topology project proposed out there, or there was.
15:33:47 <kevinbenton> but yeah, for now lets leave as won't fix until some more requirements come in
15:33:55 <mestery> ++
15:34:06 <dougwig> i think going the route of understanding topology is much harder than saying, 'yo, go write a scheduler class.'
15:34:21 <dougwig> i'm fine with won't fix for now, that's a can of worms that needs more demand, as carl_baldwin said.
15:34:28 <kevinbenton> some topology knowledge is going to be required for some of the routed networks stuff...
15:34:40 <kevinbenton> mapping of networks to hosts
15:34:45 <mestery> OK, lets move on to the next shed
15:34:48 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1464465
15:34:48 <openstack> Launchpad bug 1464465 in neutron "binding_type improvements to simplify Nova interactions" [Undecided,Confirmed]
15:34:55 <mestery> An "oldie but a goodie" for sure
15:35:05 <mestery> And I'm not even sure how valid this is anymore given Jay's move to get the VIF code out of nova into a library
15:35:44 <mestery> Also, Ian's nova spec wasn't approved
15:35:53 <dougwig> kevinbenton: having to understand topology is going to be a never-ending pile of suck, as we attempt to grok *every* twisted topology in existence over time. still seems like a scheduling concept to me, of which topology is just one case.
15:36:40 <kevinbenton> dougwig: yeah, it's a scheduling restriction thing
15:36:49 <kevinbenton> mestery: this seems reasonable pending the nova changes
15:37:16 <kevinbenton> mestery: it would be nice to just tell nova which bridges it needs to plug into for example rather than hoping the configs are right on both sides
15:37:24 <mestery> kevinbenton: ++
15:38:05 <amotoki> kevinbenton: ++
15:38:13 <mestery> kevinbenton: Comment as such and we'll move on
15:38:49 <mestery> Up next
15:38:56 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1464793
15:38:56 <openstack> Launchpad bug 1464793 in neutron "Add a driver for isc-dhcpd" [Undecided,Confirmed] - Assigned to Shraddha Pandhe (shraddha-pandhe)
15:39:01 <mestery> isc-dhcpd driver
15:39:09 <mestery> carl_baldwin: Are we ready for this yet? :)
15:39:19 * carl_baldwin reading...
15:40:32 <carl_baldwin> I don’t know if we’re ready yet.
15:40:47 <mestery> carl_baldwin: Can you comment as such in the bug and we'll move on?
15:40:47 <jaypipes> mestery: the os_vif stuff is being revived this week. I have folks in my teams that will be working on it in Mitaka.
15:40:58 <mestery> jaypipes: ++, awesome and thanks!
15:41:09 <kevinbenton> i'm not particularly interested in maintaining another dhcp driver in tree
15:41:10 <carl_baldwin> mestery: I’ll take it.
15:41:15 <kevinbenton> because it will be untested
15:41:19 <kevinbenton> in the gate
15:41:35 <mestery> kevinbenton: Well, it could be in it's own repo then
15:41:40 <mestery> Once we make DHCP pluggable
15:41:45 <mestery> So I agree
15:41:47 <mestery> Next up
15:41:51 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1467471
15:41:51 <openstack> Launchpad bug 1467471 in neutron "RFE - Support Distributed SNAT with DVR" [Undecided,Confirmed] - Assigned to Takanori Miyagishi (miyagishi-t)
15:41:54 <kevinbenton> right, isn't it pluggable already?
15:42:08 <dougwig> kevinbenton: so which one is the one we should support?
15:42:37 <mestery> dougwig: I'd be hard pressed to move to isc-dhcpd anywhere before Nxxx
15:42:52 <kevinbenton> dougwig: probably the one we already are until we see that the isc-dhcpd driver is that much better
15:42:52 <dougwig> mestery: that wasn't the question that i asked.
15:43:05 <mestery> dougwig: Then my answer is dnsmasq
15:43:18 <mestery> I think we'd have to reevaluate once isc-dhcpd exists
15:43:30 <mestery> It's kind of like saying we're going to back OVN at this point over the reference implementation.
15:43:35 <mestery> Too early
15:43:53 <dougwig> fair enough.
15:43:56 <salv-orl_> mestery: it
15:44:01 <salv-orl_> is a bit different actually
15:44:20 <carl_baldwin> On the DVR SNAT thing.  They don’t propose how they plan to distribute SNAT.
15:44:21 <salv-orl_> isc-dhcpd is part of the data plane which is still manipulated by the reference control plane
15:44:32 <salv-orl_> but still this too is not relevant to the discussion
15:45:07 <kevinbenton> while we're visiting the replacement of DHCP, what about a thing taylored to our use case? we don't use a lease database at all...
15:45:07 <salv-orl_> kevinbenton has a good point that he does not feel his team has the ability to take the mainteinance burden for this driver
15:45:20 <dougwig> 15 minute warning
15:45:31 <carl_baldwin> If no one objects, I’m going to put a comment on the DVR one to elaborate on it and mark it incomplete.
15:45:34 <amotoki> re DVR SNAT thing, I would suggest the author to propose more detail for dsicussion to move it forward.
15:45:35 <salv-orl_> kevinbenton: why don't we get rid of DHCP altogether ;)
15:45:36 <mestery> carl_baldwin: ++
15:45:42 <kevinbenton> a script written in OHascala
15:45:47 <mestery> config drive #ftw?
15:46:13 <kevinbenton> carl_baldwin: ++ getting southbound traffic to the different nodes requires some coordination with the upstream router
15:46:13 <salv-orl_> mestery: SLAAC and v6 only.
15:46:29 <dougwig> mestery: eww, config drive requires per guest support.  dhcp is everywhere.
15:46:30 <mestery> nice :)
15:46:44 <mestery> dougwig: I was joking :)
15:47:04 <dougwig> mestery: it wasn't funny.  :)
15:47:11 <mestery> :)
15:47:14 <kevinbenton> *shots fired*
15:47:15 <carl_baldwin> kevinbenton: Right.  Or buring more IPs.  Or sharing IPs between tenants.  Each of the proposed solutions have some group that objects to it.
15:48:15 <kevinbenton> carl_baldwin: yeah, shake down the submitter for more info
15:48:27 <mestery> Moving right along (12 minutes left)
15:48:30 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1468236
15:48:30 <openstack> Launchpad bug 1468236 in neutron "enable neutron support distributed DHCP agents" [Undecided,Confirmed]
15:48:33 <mestery> Huzzah!
15:48:40 <mestery> We're on a hot streak of DHCP here
15:48:47 <russellb> in OVN, plan is to drop DHCP server requirement by adding basic DHCP responder with flows, which will be distributed of course :)
15:49:02 <russellb> i'm really good about talking about all the awesome stuff we don't have yet
15:49:07 <mestery> :)
15:49:08 <mestery> lol
15:49:27 <mestery> This one has a spec even: https://review.openstack.org/#/c/205429/
15:50:12 <kevinbenton> russellb: yeah, i wish we could do that in our l2 agent, but stupid rootwrap ... :'(
15:50:32 <russellb> kevinbenton: why can't you do it?  just ovs-ofctl too slow?
15:50:45 <russellb> didn't the native openflow driver go in?
15:50:59 <mestery> russellb: It did, but regXboi found perf issues with it
15:51:03 <mestery> I think you and he discussed yesterday
15:51:09 <russellb> mestery: that was about the native ovsdb driver
15:51:13 <russellb> ovs-vsctl vs ovs-ofctl
15:51:14 <russellb> heh
15:51:25 <mestery> heh :)
15:51:39 <mestery> Anyways, since this one has a spec, I guess w'ell continue reviewing on that
15:51:41 <mestery> And lets move on here
15:51:43 <kevinbenton> russellb: no, not openflow based. have the l2 agent just attach to the network with a tap interface and respond with dhcp packets
15:51:55 <kevinbenton> mestery: right, i need to read this spec more
15:51:59 <russellb> kevinbenton: oh ok
15:52:06 <dougwig> 8 minute warning.
15:52:12 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1468366
15:52:12 <openstack> Launchpad bug 1468366 in neutron "RFE - Logging API for security group and firewall rules" [Undecided,Confirmed] - Assigned to Yushiro FURUKAWA (y-furukawa-2)
15:52:19 <kevinbenton> russellb: want something that works for linuxbridge as well
15:52:24 <mestery> This one was pretty contentious during Liberty
15:53:21 <kevinbenton> defer to next week :)
15:53:31 <mestery> Yes
15:53:45 <mestery> Speaking of defering ...
15:53:47 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1468803
15:53:47 <openstack> Launchpad bug 1468803 in neutron "Modular L2 Agent" [Undecided,Confirmed]
15:53:54 <russellb> contentions because of the API?  or the concept?
15:53:55 <russellb> or both?
15:53:58 <kevinbenton> let's do it!
15:54:08 <kevinbenton> russellb: API i think
15:54:10 <mestery> russellb: Both I think
15:54:25 <kevinbenton> russellb: then there were also grumblings about the log destinations IIRC
15:54:27 <mestery> I mean, the concept could mean a lot of things and people kept exploding it a bit. But I won't paint that shed today :)
15:54:29 <mestery> kevinbenton: Right
15:54:36 <russellb> kevinbenton: ah, yes
15:55:00 <russellb> re: modular L2 agent ... sounds great to me in theory :)
15:56:02 <dougwig> we should go full modular and just make the "modular agent agent"
15:56:05 <kevinbenton> there are two things here
15:56:06 <mestery> kevinbenton: Seems like you and amotoki agreed, shall we move this to Triaged to let it move forward?
15:56:16 <mestery> dougwig: MOAR MODULAR!
15:56:18 <salv-orl_> dougwig: that's being metadoular
15:56:19 <kevinbenton> one is elimating duplication between linux bridge and OVS
15:56:24 <salv-orl_> metamodular
15:56:25 <russellb> moduler layers modular agent
15:56:27 <kevinbenton> which i'm all for
15:56:27 <armax> kevinbenton: modular l2 agent is -=2
15:56:29 <armax> -2
15:56:42 <armax> at least the way we have ml2 plugin
15:56:44 <kevinbenton> but i don't want a huge multiple drivers framework
15:56:52 <salv-orl_> you cannot but love a  PTL whose only words are "-2"
15:56:54 <armax> moduler yes
15:56:55 <russellb> kevinbenton: +1
15:56:55 <mestery> welcome to the last 4 minutes of the meeting Mr. PTL :)
15:56:56 <kevinbenton> armax: right, that's what i was getting at before you interrupted
15:57:01 <kevinbenton> :)
15:57:02 <russellb> kevinbenton: very nice practical way to put it
15:57:09 <armax> modular l2 the way we know it, not so much
15:57:13 <mestery> kevinbenton: ++ on no multiple drivers
15:57:14 <mestery> icky
15:57:25 <amotoki> the concept is good, but the concept of agent extnesion is introeduced in the qos work. the approach needs to be revisted.
15:57:27 <armax> kevinbenton: I wasn’t interrupting…I was only providing my scarred perspective
15:57:31 <armax> :)
15:57:36 <kevinbenton> but the LB agent and OVS agent are stupid close
15:57:45 * jaypipes creates driver for Ms. Daisy
15:58:15 <russellb> kevinbenton: sounds like refactoring those 2 would be a good focused baby step
15:58:21 <kevinbenton> russellb: yes
15:58:38 <russellb> and it very well may lead to a nice place to plug in some other widget ...
15:58:43 <kevinbenton> AbstractAgentFactoryInterfaceBuilder!
15:58:49 <russellb> lol
15:59:06 <jaypipes> kevinbenton: that's called Zope.
15:59:20 <russellb> can it support loading Java plugins please
15:59:25 <jaypipes> heh
15:59:48 <mestery> OK
15:59:52 <kevinbenton> any more?
15:59:55 <mestery> I think we're done.
15:59:56 <mestery> Untiul next week!
15:59:57 <mestery> #endmeeting