22:00:59 <carl_baldwin> #startmeeting neutron_drivers
22:01:00 <openstack> Meeting started Thu Jun  2 22:00:59 2016 UTC and is due to finish in 60 minutes.  The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:02 <amuller> hiya
22:01:05 <openstack> The meeting name has been set to 'neutron_drivers'
22:01:23 <Swami> hi
22:01:24 <carl_baldwin> So, the marching orders are to continue going through the list of triaged bugs.
22:01:40 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:02:23 <carl_baldwin> Anyone got anything before we start?
22:02:43 <dougwig> no, let's beat the DLM horse some more.
22:03:01 <carl_baldwin> Okay, first up is ...
22:03:04 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1552680
22:03:04 <openstack> Launchpad bug 1552680 in neutron "[RFE] Add support for DLM" [Wishlist,Triaged] - Assigned to John Schwarz (jschwarz)
22:03:17 <amuller> John added a doc with his plan how to test performance implications of Tooz with different backends
22:03:25 <njohnston> o/
22:03:44 <dougwig> i see a note about benchmarks, but no data?
22:03:47 <amuller> I encourage stakeholders to take a look at the doc and comment before John runs off and burns CPU cycles
22:03:54 <carl_baldwin> I did not see the doc.  Looks like it appeared within the last day.
22:03:54 <dougwig> ahh, gotcha.
22:04:09 <amuller> dougwig: it's a plan and a request for comments
22:04:14 <amuller> before the data :)
22:04:42 <carl_baldwin> Okay, so without having reviewed the plan, can we do more than just say "let's review the plan?"
22:04:54 <amuller> prolly not
22:04:57 <dougwig> just reviewed and commented.
22:05:03 <amuller> that was quick =p
22:05:06 <dougwig> it's a fast read.
22:05:15 <dougwig> the test will be much more time consuming.  :)
22:05:33 <amuller> seems like the doc is read only
22:05:48 <amuller> I'll ask John to enable comments, I find it much easier to add comments on the google doc than on launchpad
22:05:48 <dougwig> i commented in the bug
22:07:14 <amuller> dougwig: the first bullet point in the second group of bullet points is the 'no tooz' option
22:07:18 <amuller> As I understand it anyway
22:07:49 <dougwig> indeed, i read too quickly.
22:08:23 <carl_baldwin> Ok, let's all review it.  Having comments on will be helpful.
22:08:34 <carl_baldwin> Anything more?
22:09:30 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1559978
22:09:30 <openstack> Launchpad bug 1559978 in neutron "[RFE] log segmentation_id over threshold for monitoring" [Wishlist,Triaged]
22:09:56 <carl_baldwin> armax summed it up:  "as an admin I want to know how many Neutron networks I have left at my disposal before my tenants start complaining that their neutron net-create command failed"
22:10:04 <carl_baldwin> At least that's the way I understand it.
22:10:34 <carl_baldwin> Thoughts?
22:11:17 <amuller> I think that something like Calico doesn't use segmentation IDs
22:11:24 <dougwig> seems closely related to liberty's effort for an api to check remaining ips.
22:11:31 <amuller> so the concern is that an API wouldn't be plugin agnostic
22:13:12 <carl_baldwin> I don't think it could be plugin agnostic.
22:13:24 <amuller> you know, on the other hand this is really only relevant for VLANs
22:13:57 <amuller> if you're using tunnels I don't think this RFE is useful or relevant
22:14:07 <carl_baldwin> Other plugins could somehow report that it is irrelevant.
22:14:28 <amuller> so if this is specific to VLANs, we could treat it as such, then it becomes easy for any plugin (That uses VLANs) to implement
22:14:42 <HenryG> yup, like the ip availability issue is not really relevant for IPv6
22:16:01 <carl_baldwin> HenryG: what you haven't used the 1.8446744e+19 IPs in your subnet yet?
22:16:06 <amuller> How would a monitoring system use an API though?
22:16:22 <amuller> Polling doesn't seem realistic
22:16:31 <dougwig> don't tell SNMP that.
22:17:06 <dougwig> a poll period of an hour is likely plenty in this scenario. i don't think the info delivery mechanism is the issue here.
22:17:23 <carl_baldwin> amuller: Its always nice when things tell you proactively that they're sick but we don't get a lot of that with monitoring.
22:18:31 <carl_baldwin> So, is it worth the effort to design an API?  (question posed by armax in bug)
22:19:07 <dougwig> true, but polling is the LCD of most monitoring systems (and those systems usually provide a common notification mechanism.) i'm not sure we need to reinvent that wheel.
22:19:43 <amuller> Would a clear log level at INFO level serve the use case better than an API you'd have to poll?
22:20:20 <amuller> that is assuming you run a log aggregator
22:21:21 <amuller> I think we're discussing solutions to a problem without a well defined user
22:21:39 <amuller> So how could we design an API
22:21:43 <amuller> or any other solution
22:21:53 <amuller> it'd be a guess at best
22:22:06 <carl_baldwin> Logging something would be very easy.
22:22:21 <carl_baldwin> Actually, the rfe originally asked for a log, didn't it?
22:22:53 <amuller> carl_baldwin: I don't think a patch that adds a log in that event would need to go through the RFE process anyhow
22:24:44 <amuller> I'd suggest that Miguel takes up a patch that adds logging if he's up for it, and for any further work, Miguel can start a thread on the ML, asking for input from Monasca people
22:25:11 <HenryG> Why was ip availability not done with INFO logging?
22:25:34 <carl_baldwin> I don't know.
22:25:47 <dougwig> i don't think anyone ever suggested it/thought of it.
22:25:53 <boden> Random thought; if #link https://review.openstack.org/#/c/308973/  ever gets approved perhaps it could be implemented as a health check; depending on where/if that spec lands
22:25:58 <carl_baldwin> We've spent quite a lot of time on this and I don't have strong feelings about any direction.
22:25:59 <amuller> I thought that ip availability was supposed to be used by Nova at some point
22:26:18 <dougwig> no, it was an operator request
22:26:39 <amuller> yeah, but I remember that surfaced as a second use case on the RFE bug / spec
22:26:39 <HenryG> dougwig: yeah, but what amuller says rings a bell too
22:27:10 <amuller> carl_baldwin: wasn't this a part of the big deployers team requirements?
22:27:19 <amuller> to schedule based off IP availability?
22:27:51 <carl_baldwin> amuller: I think it was for some operators who are already doing something like routed networks on their own.
22:28:00 <amuller> right
22:28:29 <carl_baldwin> But, the real solution with Nova is going to look very different.  Possibly leveraging some of that work.
22:29:06 <carl_baldwin> I sense we're not really getting anywhere on this RFE.
22:29:44 <amuller> Go with logging first, solicit more input for any further work?
22:29:50 <carl_baldwin> Maybe we just suggest moving forward with logging?
22:30:02 <carl_baldwin> Anyone object?
22:30:52 <carl_baldwin> Okay, let's move on...
22:31:00 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1561824
22:31:00 <openstack> Launchpad bug 1561824 in neutron "[RFE] Enhance BGP Dynamic Routing driver with Quagga suppport" [Wishlist,Triaged] - Assigned to steve (ruansx)
22:31:39 <carl_baldwin> At this point, with BGP broken out, this one should be contained to the dynamic routing repo.
22:31:57 <carl_baldwin> Also, BGP already has a pluggable architecture.
22:32:17 <mickeys> Yes, the intent is to target this for the dynamic routing repo
22:32:32 <carl_baldwin> Any reason not to approve it?
22:32:52 <HenryG> This would also allow the team to build a reference implementation for CI
22:33:10 <HenryG> No objection here
22:33:13 <carl_baldwin> HenryG: There is a reference impl based on Ryu.
22:33:53 <carl_baldwin> But, there are some limitations to Ryu.  Like having multiple speakers.
22:34:24 <carl_baldwin> Any other thoughts?
22:34:49 <carl_baldwin> Okay.
22:35:05 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1563879
22:35:05 <openstack> Launchpad bug 1563879 in neutron "[RFE] DVR should route packets to Instances behind the L2 Gateway" [Wishlist,Triaged]
22:36:14 <carl_baldwin> I'm not up to date on this one.
22:37:38 <carl_baldwin> Mostly, I'm confused about armax 's last comment.  The link circles back to the rfe.
22:37:51 <carl_baldwin> Maybe we should just shelve this until he returns and move on.
22:38:45 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1566191
22:38:46 <openstack> Launchpad bug 1566191 in neutron "[RFE] Allow multiple networks with FIP range to be associated with Tenant router" [Wishlist,Triaged]
22:39:21 <carl_baldwin> I think we're still at the same point we were.  We're going to unblock the fix and possibly discuss later.
22:40:27 <carl_baldwin> I'm going to skip the fast exit one too because armax is having on-going discussion with tidwellr on that bug.
22:40:50 <carl_baldwin> Still with me?
22:40:58 <njohnsto_> o/
22:41:03 <HenryG> yes
22:41:13 <amuller> yep
22:41:23 <carl_baldwin> njohnsto_: HenryG:  amuller:  Thanks.
22:41:47 * carl_baldwin starting to know how armax feels in this meeting. It feels a bit one-sided.
22:42:23 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1579068
22:42:23 <openstack> Launchpad bug 1579068 in neutron "[RFE] Multiple VXLAN multicast groups in linuxbridge" [Wishlist,Triaged]
22:43:11 <amuller> sounds like the next step would be to have LB agent folks chime in on the bug
22:43:31 <carl_baldwin> Right, any LB experts out there?
22:43:58 <carl_baldwin> Anyone know why the vxlan group was considered a single attribute?
22:44:03 <haleyb> that's sc68cal, right? :)
22:45:15 <carl_baldwin> So, how do we go about getting such feedback?
22:45:38 <carl_baldwin> Recommend going to the ML?
22:45:50 <amuller> carl_baldwin: +1
22:46:45 <carl_baldwin> That's what I'll do.
22:46:52 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1581931
22:46:52 <openstack> Launchpad bug 1581931 in neutron "RBAC -access_as_external - exclude tenant" [Wishlist,Triaged]
22:47:20 <carl_baldwin> Doesn't sound very compelling to me.
22:48:17 <carl_baldwin> kevinbenton says it will be quite a bit of work.
22:48:38 <carl_baldwin> Won't fix for now?
22:49:53 * carl_baldwin needs a gavel to slam down and wake everyone up. ;)
22:50:51 <amuller> carl_baldwin: +1
22:50:58 <HenryG> Well, does the submitter have a fix?
22:51:02 <amuller> HenryG: no
22:51:06 <carl_baldwin> no
22:51:27 <HenryG> Then +1 for won't fix
22:51:37 <carl_baldwin> Done.
22:51:47 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1583184
22:51:47 <openstack> Launchpad bug 1583184 in neutron "[RFE] bgp-dynamic-routing router association" [Wishlist,Triaged]
22:52:13 <carl_baldwin> My concern with this is tidwellr is pretty busy with other stuff.
22:52:32 <carl_baldwin> I might put this back on the confirmed list until we identify someone who can do the work.
22:52:55 <carl_baldwin> Anyone else have thoughts?
22:53:17 <amuller> carl_baldwin: You *might* get a volunteer with a ML thread
22:53:25 <amuller> worth a shot IMO if the issue is lack of assignee
22:53:42 <HenryG> Yamamoto is doing it for midonet only?
22:54:36 <carl_baldwin> Looks like they already merged a spec for it.
22:55:05 <carl_baldwin> ... just this morning.
22:55:14 <carl_baldwin> I'll figure out what is going on here this week.
22:55:19 <carl_baldwin> ... and report back next week.
22:55:23 <HenryG> Oh, they need support in dynamic-routing repo
22:55:36 <tidwellr> HenryG: it's not just for midonet, it's something we wanted to support from the get-go but it never made it up the priority list
22:56:02 <HenryG> tidwellr: understood, but that's where it originated
22:56:14 <carl_baldwin> tidwellr: Can we give them the support they need for this?
22:56:54 <tidwellr> carl_baldwin: I can commit to review cycles and *some* hand-holding, but I'm stretched pretty thin
22:57:54 <carl_baldwin> tidwellr: Does this touch the neutron repo or other repo outside of dynamic routing?
22:58:14 <tidwellr> carl_baldwin: no, it doesn't touch the neutron repo
22:58:19 <carl_baldwin> ok.
22:58:45 <carl_baldwin> We're only got a minute left.  I say we draw the line here.
22:58:53 <carl_baldwin> s/We're/We've/
22:59:00 <carl_baldwin> Any objections?
22:59:06 <njohnston> +1
22:59:13 <HenryG> +1
22:59:18 <carl_baldwin> #endmeeting