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