22:01:36 <kevinbenton> #startmeeting neutron_drivers
22:01:37 <openstack> Meeting started Thu Jun  9 22:01:36 2016 UTC and is due to finish in 60 minutes.  The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:41 <openstack> The meeting name has been set to 'neutron_drivers'
22:02:17 <kevinbenton> armax didn't give me specific instructions
22:02:24 <kevinbenton> so i assume we continue with triaging
22:02:38 <kevinbenton> does anyone have anything they want to bring up first?
22:03:40 <kevinbenton> ok, triaging it is then
22:03:43 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:04:15 <kevinbenton> first up is https://bugs.launchpad.net/neutron/+bug/1552680
22:04:15 <openstack> Launchpad bug 1552680 in neutron "[RFE] Add support for DLM" [Wishlist,Triaged] - Assigned to John Schwarz (jschwarz)
22:04:23 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1552680
22:04:33 <kevinbenton> amuller: any updates on that front ^^ ?
22:04:51 <amuller> John added initial numbers to the google doc linked from the RFE
22:05:24 <amuller> https://docs.google.com/document/d/1jdI8gkQKBE0G9koR0nLiW02d5rwyWv_-gAp7yavt4w8/edit
22:05:51 <amuller> And looking at the results, they are unexplainable :)
22:06:13 <amuller> So John is looking in to it, for example why is the minimum with DLM lower than without.
22:06:45 <amuller> In other words, more to come.
22:07:23 <kevinbenton> amuller: ack. considering the deviation of each it could easily have been luck
22:07:37 <kevinbenton> amuller: the rest of the numbers seem to make sense
22:08:00 <amuller> kevinbenton: that's what we thought, but he ran it so many times on systems that are otherwise unused, so we don't exactly understand what's going on right now, but he'll look in to it
22:08:12 <kevinbenton> amuller: sounds good
22:08:41 <amuller> kevinbenton: To me, the average is scary
22:09:00 <amuller> kevinbenton: this is a very simple usage of DLM, without any contention, because the lock is on the router_id, and the test is only operating on different routers
22:09:18 <amuller> so adding 10% to router_create+delete is a bigger impact than I had thought
22:10:38 <kevinbenton> ok, well we can wait for more numbers
22:10:58 <kevinbenton> lets move onto the next one
22:11:03 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1559978
22:11:03 <openstack> Launchpad bug 1559978 in neutron "[RFE] log segmentation_id over threshold for monitoring" [Wishlist,Triaged]
22:11:31 <amuller> I thought we agreed that the initial direction will simply add a log.
22:12:19 <carl_baldwin> Maybe I should've moved this to approved.  ?
22:12:20 <kevinbenton> ah yes, i see
22:12:23 <kevinbenton> yeah
22:12:44 <kevinbenton> technically the stuff is sort of aggregatable via the admin get_networks call
22:12:53 <kevinbenton> they can see segmentation_ids
22:13:15 <amuller> I think the RFE tag should be removed entirely and this should be treated as just a patch
22:13:25 <amuller> if anyone wants to tackle this in a more comprehensive manner they could re-open the rfe
22:13:43 <kevinbenton> yeah, i think removing rfe if logging is the initial direction sounds good
22:14:19 <carl_baldwin> I'll do it.
22:14:27 <amotoki> I agree to start with simple logging and remove rfe tag
22:14:56 <kevinbenton> next up is #link https://bugs.launchpad.net/neutron/+bug/1563879
22:14:56 <openstack> Launchpad bug 1563879 in neutron "[RFE] DVR should route packets to Instances behind the L2 Gateway" [Wishlist,Triaged]
22:15:05 <kevinbenton> looks like it was discussed as well
22:16:04 <kevinbenton> but i'm not sure what it has to do with l2gw
22:16:28 <kevinbenton> oh, nevermind
22:17:30 <kevinbenton> should this have been marked as confirmed?
22:18:47 <carl_baldwin> I'm not sure what to do with this one right now.
22:19:06 <kevinbenton> ok, we'll just leave it as is then
22:19:34 <amotoki> do we need to discuss more content on the linked spec review?
22:20:03 <amotoki> at least it seems we haven't figured out what we need.
22:21:20 <kevinbenton> amotoki: where is the spec?
22:21:41 <amotoki> woops..... sorry it was not a spec. just a l2gw review.
22:21:55 <ihrachys> and a small one
22:23:02 <kevinbenton> i'm not familiar enough with l2gw
22:23:24 <kevinbenton> might have to wait for armax
22:23:55 <kevinbenton> let's move to the next one
22:23:58 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1566191
22:23:58 <openstack> Launchpad bug 1566191 in neutron "[RFE] Allow multiple networks with FIP range to be associated with Tenant router" [Wishlist,Triaged]
22:24:07 <kevinbenton> this was discussed a couple of times
22:24:37 <kevinbenton> i think we ended up just fixing the regression
22:24:38 <carl_baldwin> I think we need to just close it out.
22:25:02 <kevinbenton> what's the appropriate status to set it to?
22:25:06 <kevinbenton> fix_commited?
22:25:13 <carl_baldwin> I'm thinking won't fix
22:25:20 <kevinbenton> ok
22:25:38 <carl_baldwin> Then, someone could try to reopen it later if there is interest in working on the ref impl.
22:25:38 <kevinbenton> carl_baldwin: can you do that?
22:25:43 <carl_baldwin> on it
22:26:08 <amotoki> it there a way to achieve what is requested in this rfe?
22:27:23 <kevinbenton> i think it worked by accident with reference implementaiton if you allocated a floating IP from a regular router tenant interface
22:27:28 <kevinbenton> carl_baldwin: does that sound right?
22:27:50 <carl_baldwin> kevinbenton: Yes, that's about it.
22:27:59 <amotoki> yeah. it worked by acciedent.
22:28:02 <carl_baldwin> kevinbenton: wait
22:28:10 <carl_baldwin> In the reference implementation?
22:28:18 <carl_baldwin> It worked by accident in Midonet, right?
22:28:23 <kevinbenton> oh
22:28:44 <kevinbenton> maybe
22:28:59 <carl_baldwin> I don't think it works in the reference impl.
22:29:18 <kevinbenton> either way, it's not something we intended to support in the reference
22:29:55 <carl_baldwin> kevinbenton: right
22:29:56 <kevinbenton> next up
22:29:59 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1577488
22:29:59 <openstack> Launchpad bug 1577488 in neutron "[RFE]"Fast exit" for compute node egress flows when using DVR" [Wishlist,Triaged]
22:30:08 <kevinbenton> i think we can mark this as confirmed, no
22:30:09 <kevinbenton> ?
22:30:33 <kevinbenton> or did we experience a regression in our stance as of last week? :)
22:31:57 <carl_baldwin> I left it open because there was still some discussion going on.  So, we skipped it last week.
22:32:19 <kevinbenton> ok
22:32:25 <kevinbenton> has it resolved yet?
22:32:32 <kevinbenton> not clear based on the last comments
22:32:47 <carl_baldwin> I'm not sure.
22:33:25 <kevinbenton> ok, might have to wait for armax since he was the dissenting opinion!
22:34:02 <kevinbenton> which brings up #link https://bugs.launchpad.net/neutron/+bug/1585770
22:34:02 <openstack> Launchpad bug 1585770 in neutron "[RFE] DVR-aware fixed IP announcements for with BGP" [Wishlist,Triaged]
22:34:03 <carl_baldwin> ya
22:34:34 <kevinbenton> this makes sense to me
22:34:41 <carl_baldwin> me too
22:34:51 <kevinbenton> it should be pretty simple as well assuming the previous just always does fast exit
22:35:55 <kevinbenton> shall we wait for armax to mark it as confirmed?
22:36:06 <kevinbenton> or does anyone here have any issues with it?
22:36:23 <carl_baldwin> kevinbenton: You mean rfe-approved?  Confirmed actually comes before Triaged.
22:36:29 <amotoki> kevinbenton: do you mean approved instead of confirmed?
22:36:32 <kevinbenton> sorry, wrong state
22:36:35 <kevinbenton> yeah, approved
22:36:44 * carl_baldwin gets confused by rfe states too.
22:37:18 <dougwig> there 9 pages of description somewhere in the neutron docs.
22:37:28 <kevinbenton> :)
22:37:39 <amuller> imagine people that don't work on neutron every day...
22:38:01 <kevinbenton> refer them to this diagram
22:38:02 <kevinbenton> http://www.micromouseonline.com/wp/wp-content/uploads/2014/05/diagonal-pathfinder.png
22:38:39 <amuller> kevinbenton: perfect
22:38:42 <kevinbenton> carl_baldwin: can you mark as approved for that BGP one?
22:38:51 <carl_baldwin> kevinbenton: ok
22:38:56 <amotoki> if we approve it, do we suggest a spec for this?
22:38:59 * carl_baldwin consults the diagram
22:39:22 <carl_baldwin> amotoki: I don't need a spec.  How about others?
22:39:38 <amotoki> it seems simple enough.
22:40:17 <kevinbenton> i don't think so
22:41:06 <kevinbenton> ok. last on the list is this topology thing #link https://bugs.launchpad.net/neutron/+bug/1586584
22:41:07 <openstack> Launchpad bug 1586584 in neutron "Get the virtual network topology" [Wishlist,Triaged]
22:41:37 <kevinbenton> sounds to me like a nice feature for neutron client or openstack client
22:41:50 <dougwig> isn't this already in horizon?
22:41:56 * amuller shrugs
22:42:21 <dougwig> this goes beyond the scope of a CRUD get.  -1 from me.
22:42:21 <kevinbenton> nothing new in the output that isn't already available via various APIs
22:42:36 <amuller> dougwig +1
22:42:46 <amuller> as evident by the back and forth in that rfe
22:42:53 <ihrachys> I would endorse a separate tool that does just that. outside of neutron stadium.
22:43:05 <amotoki> all information can be retrieved thru API. In my understanding this RFE just requests to display information in a convenient way.
22:43:25 <kevinbenton> ok, so is "Won't Fix" the appropriate state then?
22:43:35 <kevinbenton> or is this something we could consider on the neutron client?
22:43:41 <dougwig> i think it's "invalid" when filed against a rest api, tbh.
22:43:55 <kevinbenton> neutron-specs covers neutronclient though, no?
22:44:06 <amotoki> at least invalid in neutron side.
22:44:13 <amuller> dougwig: the question is "wontfix" or switch the component to the client
22:44:22 <kevinbenton> right
22:44:24 <ihrachys> switch and then won't fix :)
22:44:27 <amotoki> i am not sure how CLI output helps it. do you think an example output is useful?
22:44:41 <amuller> amotoki: there is example output in the bug report
22:45:00 <HenryG> amotoki: this is in horizon now? https://blueprints.launchpad.net/horizon/+spec/curvature-network-topology
22:45:21 <amuller> it is
22:45:23 <amotoki> amuller: yes. i see it, but i am not sure the example output is so useful
22:45:47 <kevinbenton> HenryG: right, but an operator may not want to look in horizon
22:46:01 <kevinbenton> that wiggly thing isn't greppable
22:46:54 <HenryG> The code that collects the info can be re-used and push out some text
22:47:00 <HenryG> ?
22:47:15 <kevinbenton> right, and we can put that code in the client as a helper command
22:47:30 <kevinbenton> or we can say we aren't interested
22:47:33 <amotoki> I am okay to support it in a client side. all needed information are available through API.
22:48:31 <kevinbenton> so how do we retarget this to the client?
22:48:35 <kevinbenton> we would need a volunteer
22:48:40 <amuller> amotoki: in the openstack client, right?
22:48:50 <amuller> amotoki: or are we still implementing new features in the neutron client?
22:49:23 <amotoki> amuller: in general, it goes to openstackclient
22:49:40 <amotoki> but i think we need to discuss with osc folks.
22:50:18 <amotoki> i think it is similar to 'purge' command because it does a kind of orchestration.
22:50:39 <amuller> kevinbenton: I switched the component
22:50:57 <amuller> amotoki: I think we need to move the purge command too
22:51:20 <amuller> that's a separate discussion though
22:51:28 <amotoki> amuller: yes we need to move 'purge' command
22:51:40 <amotoki> it is a part of osc migration
22:52:12 <dougwig> it could easily be done as a neutronclient extension in another package, btw.
22:52:55 <kevinbenton> right
22:53:15 <amotoki> dougwig: it can. we need a guideline which commands are provided thru osc plugin and which should go to native OSC commands.
22:53:36 <kevinbenton> but this use case isn't really specific to any type of deployment or anything
22:53:43 <kevinbenton> not sure it needs to be isolated in a plugin
22:54:53 <amotoki> it seems i was confused with OSC plugin and neutornclient extension :(
22:55:38 <kevinbenton> ok, well i think we've at least agreed that this doesn't belong in the server at all
22:55:48 <kevinbenton> and it could potentially be a helper command in a client
22:56:16 <amotoki> +1
22:56:23 <kevinbenton> that's the last of them on the list
22:56:32 <kevinbenton> anyone have anything else before ending the meeting?
22:56:43 <kevinbenton> #topic OPEN DISCUSSION!
22:57:57 <kevinbenton> #endmeeting