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