22:00:40 #startmeeting neutron_drivers 22:00:42 Meeting started Thu Mar 9 22:00:40 2017 UTC and is due to finish in 60 minutes. The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:00:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:00:46 The meeting name has been set to 'neutron_drivers' 22:00:54 ihrachys, armax, amotoki: ping 22:01:10 o/ 22:01:31 hi 22:01:59 looks like Akihiro may be absent 22:02:24 shall we review some RFEs now or should we maybe try to find some new folks to join the drivers team for next week? 22:02:35 both? 22:02:53 we punted several meetings 22:03:09 yeah, it feels strange to make decisions with 1-2 people 22:03:17 let's see if we can get some non-contentious stuff done 22:03:39 is there anything in the approved pipeline worth going over into? 22:03:52 or pike-1 targeted stuff that needs attention? 22:04:10 we don’t necessarily have to talk about unapproved RFEs if the existing workload is not moving at the pace it should 22:04:54 P-1 is sooner than we think 22:05:12 what do you want to discuss about existing ones? 22:05:14 deferring them? 22:05:35 #link https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe-approved 22:05:54 I am talking about https://launchpad.net/neutron/+milestone/pike-1 more specifically 22:05:55 https://launchpad.net/neutron/+milestone/pike-1 22:06:48 I hear that https://blueprints.launchpad.net/neutron/+spec/l2-api-extensions may loose its approver 22:07:36 ihrachys: how so? 22:08:03 is ajo no longer able to work upstream? 22:08:09 I think ajo was going to pull himself off it though I will let him to update with specifics 22:08:14 on the OVS agent data plane? 22:08:19 armax: why no! but priorities shift 22:08:40 ok. i would rather actually bring up these blueprints already in progress in the main meeting 22:09:00 because otherwise it's hard to bring attention to the wider community on these issues 22:09:11 true 22:09:19 we can see if we have another volunteer in the next meeting to take ajo's place 22:09:22 but the main meeting is packed 22:09:27 we can at least do some filtering here 22:09:30 but you’re the boss 22:09:53 if nothing else, I think it’s long overdue to come up with a decision about https://blueprints.launchpad.net/neutron/+spec/security-group-logging 22:10:04 it’s been many releases this hasn’t gone anywhere 22:10:43 well it has been revised many times 22:10:50 I believe it was raised during ptg and the resolution was it (and similar initiatives) is blocked by ml2 binding validation work that should have gotten its own RFE 22:10:57 we’re still at the spec level 22:11:16 yes, and I think the API is agreed on now, right? 22:12:27 the last stuff is coming down to OVS implementation 22:12:58 I believe it was, yes. so should we ask ml2 folks to report BP and then we can set blueprint dependencies properly? and push work on ml2 binding validation from there? 22:14:09 why is it blocked on binding validation? 22:14:18 just ensuring that something supports the logging? 22:14:59 yeah otherwise you enable a feature but it doesn't work, and there is no api way to detect that 22:15:07 like we have for qos right now 22:16:09 and security groups 22:17:13 it's an old question of whether we should allow those cases to creep in, or block them on framework enhancement 22:18:02 in Ocata we blocked some qos feature work on rule validation enhancements. that case does seem similar. 22:18:09 right, so far we've achieved the blocking part but we're missing out on the framework enhancements :) 22:18:15 personally I’d rather build a solid framework 22:18:27 and then lay on top features than the other way around 22:18:58 kevinbenton: because no one works. now why is it? is it because people refuse to, or because they are not aware of dependency chain? 22:19:33 ihrachys: it may be the latter 22:19:40 kevinbenton: for qos, we definitely saw rule validation enhanced this cycle. partially I attribute that to the stand taken by armax 22:20:04 ihrachys: but it ended up being a qos-specific feature, no? 22:20:19 ihrachys: we can't re-use that right now, or can we 22:20:29 it was, because at that moment it was not seen as a common issue. 22:20:51 or rather qos folks were not told they gotta make it more reusable. 22:21:06 so that's our opportunity to take what landed and make it more generic 22:22:13 do we ask the security group logging folks to work on that? 22:23:02 I would think people talking about that mechanism during ptg would chime in, but yes, help from other sides would be good to see. 22:23:34 we can fix the dependency visibility, and hopefully it will help. what i'm worried about is that we are telling other people to go off and make larger architectural fixes 22:23:34 has anyone followed up with ml2 folks after ptg on that matter? I hope it won't end up as another nice thing discussed but never materialized 22:23:55 that they don't have the background knowledge to dig into 22:25:14 that's a valid concern. so who's going to dig architectural fixes? 22:25:26 i don't see the ml2 people following up with https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe&orderby=-id&start=0 22:25:46 i'll reach out to rkukura and see who is actually going to work on it 22:25:55 that makes sense 22:26:15 overall I would suggest to track ptg discussions in some medium that would avoid things slipping thru cracks. 22:26:33 some teams took over relevant notes from etherpads and oral discussions and follow up on them 22:26:41 but some may need some pokes :) 22:27:23 kevinbenton: do you want to add an action item onto yourself to follow up? #action 22:27:56 #action kevinbenton to follow up with Bob about ML2 driver capability work 22:28:14 the security group logging API is operator-only, isn't it? 22:29:50 I see what you imply. that may change the priority of validation 22:30:44 I guess with that in mind we could make a one-off exception. armax? 22:30:46 yeah, if this is operator-only, i would rather just not even make this dependent on that framework 22:31:11 because presumably the operator is aware of what backend they are using 22:31:23 one-off exception to give that a blank check? 22:32:08 define thta 22:32:10 *that 22:32:12 kevinbenton: the problem is not so much that the operator knows, it’s when you have multiple backends active at the same time and you may get impredictable results depending on where the VM lands 22:32:47 armax: and how do you think the ml2 framework would help that for operator defined things? 22:33:03 armax: it would just silently fail all user ports that end up on other mechanism drivers? 22:33:25 not sure I have an answer handy right now 22:34:19 well unless we have a clear thing the dependency would be good for in this case, maybe we shouldn't block this particular patch 22:35:59 shall we discuss some RFEs? 22:36:13 i'm going to comment on the spec 22:36:37 kevinbenton: easy one: should we close https://bugs.launchpad.net/neutron/+bug/1463784 ? 22:36:37 Launchpad bug 1463784 in neutron "[RFE] Networking L2 Gateway does not work with DVR" [Wishlist,In progress] 22:36:43 seems handled on l2gw side 22:36:54 kevinbenton: have you considered who is going to help throughout the review process if rossella doesn’t have much time? 22:37:39 as for the RFE you just mentined, this probably needs to be recycled 22:37:58 armax: what does that mean? 22:38:10 it sounds like it should be closed 22:38:46 I think there is no work on neutron side 22:38:55 so we can just Won't Fix or smth 22:39:04 i think just remove neutron 22:39:09 OK 22:39:15 I marked it invalid 22:41:00 kevinbenton: what's next? 22:41:53 https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe 22:42:21 #link https://bugs.launchpad.net/neutron/+bug/1476527 22:42:21 Launchpad bug 1476527 in neutron "[RFE] Add common classifier resource" [Wishlist,Triaged] - Assigned to Igor Duarte Cardoso (igordcard) 22:42:27 so common classifier 22:42:40 I heard Igor is working on PoC in neutron-classifier repo scope 22:43:12 yeah, it sounds like it's still out of tree for now 22:43:28 I think it's fine to leave him poking the thing and get back it once/if he has something 22:43:38 ok 22:43:47 I think no-one is opposed to the idea 22:44:06 once the effort gets some critical mass we can consider it for governance inclusion 22:44:17 and adoption in other subprojects 22:44:39 #link https://bugs.launchpad.net/neutron/+bug/1525824 22:44:39 Launchpad bug 1525824 in neutron "[RFE] Add a 'promiscuous mode' extension for ports" [Wishlist,Triaged] 22:45:02 let’s recycle this one 22:45:08 submitter never came back 22:45:12 armax: i still don't know what recycle means 22:45:22 mark incomplete 22:45:24 armax: ok 22:45:26 armax: yeah 22:45:29 so that LP bot can expire in due course 22:45:49 "If the code fails to merge, the bug report may be marked as incomplete, unassigned and untargeted, and it will be garbage collected by the Launchpad Janitor if no-one takes over in time. Renewed interest in the feature will have to go through RFE submission process once again." 22:45:50 should have marked incomplete long time ago, tbh 22:46:11 ihrachys == LP bot 22:46:13 right, but it's not like we are able to use the number again so it's not recycled :) 22:46:35 kevinbenton: the RFE can alway come back to life 22:46:52 bringing it back to life would be the recycling part :) 22:46:56 sigh 22:47:00 #link https://bugs.launchpad.net/neutron/+bug/1541895 22:47:00 Launchpad bug 1541895 in neutron "[RFE] [IPAM] Make IPAM driver a per-subnet pool option" [Wishlist,Triaged] 22:47:09 I would say mark incomplete for this one 22:47:24 until John shows resources 22:47:29 yes, we can ping John again just in case 22:47:40 armax: ok, do you want to do that? 22:47:51 done 22:48:57 #link https://bugs.launchpad.net/neutron/+bug/1610898 22:48:57 Launchpad bug 1610898 in neutron "[RFE] create "baremetal" Mechanism ML2 driver" [Wishlist,Triaged] 22:49:00 ^ That's misplaced. let's Won't Fix, it's not in our scope to maintain a driver for BM is it? 22:49:10 sounds like this can be won't fix 22:49:18 IMO no 22:49:57 I think this is won’t fix 22:50:05 https://bugs.launchpad.net/neutron/+bug/1610898/comments/6 22:50:05 Launchpad bug 1610898 in neutron "[RFE] create "baremetal" Mechanism ML2 driver" [Wishlist,Won't fix] 22:50:23 we don’t need and RFE to instrument the codebase with callbacks 22:50:24 ok 22:51:43 #link https://bugs.launchpad.net/neutron/+bug/1622753 22:51:43 Launchpad bug 1622753 in neutron "[RFE] Block non-IP traffic in security groups/firewall driver" [Wishlist,Triaged] 22:52:31 we might have lost the contributor here 22:53:17 yeah, let's ping Dustin on there and see if he wants to work on it at all 22:53:27 not sure we could do anything about this one even if we wanted to 22:53:55 we could potentially do something with a new attribute on the port 22:54:10 a new config option is a bit problematic since it's not API discoverable 22:54:10 kevinbenton: more like security group attribute? 22:54:24 ihrachys: yeah 22:54:31 ihrachys: well not quite, a port can be associated with many security groups 22:54:42 ihrachys: and this is about filtering traffic not defined by the security groups 22:54:44 it’s probably even a new resource altogether IMO 22:54:58 fwaas is it? :) 22:55:01 I wouldn’t mix the two 22:55:22 armax: what do you mean a new resource? 22:56:04 kevinbenton: I don’t think that using the security group API is going to cut it 22:56:07 armax: it seems like it will need to be a property of the port or maybe the network 22:56:10 kevinbenton: well we already should have some kind of convergence mechanism for multiple groups. it's just a matter of picking the intended behaviour on conflicting rules? 22:56:31 ihrachys: there can't be conflicting rules 22:56:36 ihrachys: security groups only denies 22:56:51 ihrachys: sorry 22:56:53 ihrachys: allows 22:56:57 ihrachys: so they compose 22:57:20 the issue is that we have an impliticit allow rule right now with one of the drivers 22:58:01 ah right 22:58:24 well let's ping Dustin, no point in deliberating if we have nobody to work on int 22:58:27 it* 22:58:34 + 22:58:40 time check 2 mins 22:59:28 aye 22:59:48 ok 22:59:53 was hoping to approve https://bugs.launchpad.net/neutron/+bug/1630981 22:59:53 Launchpad bug 1630981 in neutron "[rfe] Implement l2pop driver functionality in l2 agent" [Wishlist,Triaged] 22:59:57 since i'm not sure there is a downside 23:00:04 but we can discuss next week 23:00:07 thanks 23:00:17 I am +2 on that one 23:00:21 #endmeeting