22:02:25 <armax> #startmeeting neutron_drivers
22:02:27 <openstack> Meeting started Thu Jan 19 22:02:25 2017 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:02:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:02:30 <openstack> The meeting name has been set to 'neutron_drivers'
22:02:34 <kevinbenton> #agreed
22:02:57 <njohnston> o/
22:02:57 <armax> #chair kevinbenton
22:02:57 <openstack> Current chairs: armax kevinbenton
22:03:10 <armax> kevinbenton: since you’re so keen to use the #
22:03:10 <kevinbenton> #dechair kevinbenton
22:03:17 <armax> kevinbenton: sush
22:03:28 <armax> *shush
22:04:10 <armax> ok
22:04:13 <armax> let’s jump in
22:04:37 <armax> we have a few specs open
22:04:41 <armax> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z
22:05:10 <armax> of the ones with +2, only https://review.openstack.org/#/c/351675/ seems ready to land
22:05:33 <armax> the others have some negative feedback
22:05:49 <armax> are we ok with the port dataplane status extension?
22:05:57 <amotoki> I am okay with this.
22:06:23 <armax> ihrachys: you expressed your mild entushiasm
22:06:28 * ihrachys keeps silence
22:06:32 <armax> kevinbenton: what about you?
22:06:44 <kevinbenton> armax: +2
22:06:48 <armax> omg
22:07:06 <armax> ok
22:07:13 <armax> I’ll nudge it in after the meeting
22:07:32 <armax> before jumping into the list of triaged RFEs
22:07:46 <armax> is there anything more pressing to discuss?
22:07:50 <armax> Ocata-wise?
22:08:46 <armax> no?
22:08:54 <ihrachys> no
22:09:02 <amotoki> no
22:09:20 <armax> ok
22:09:30 <kevinbenton> NO
22:09:35 <armax> do you guys realize that this is my second to last time I ran the drivers meeting?
22:10:11 <armax> or maybe third to last
22:10:27 <ihrachys> armax: we can give you honor runs in the future
22:10:30 <kevinbenton> what about when you run for PTL for the Q cycle?
22:10:44 <armax> ihrachys: it’s a privilege I kindly decline
22:10:48 <armax> thanks though
22:11:56 <armax> ok let’s continue
22:12:12 <armax> I have these list in front of me
22:12:14 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:13:34 <armax> bug #1525824
22:13:34 <openstack> bug 1525824 in neutron "[RFE] Add a 'promiscuous mode' extension for ports" [Wishlist,Triaged] https://launchpad.net/bugs/1525824
22:14:25 <armax> any thoughts on this one?
22:14:53 <armax> I think it could be a nice addition to the ability of neutron to serve NFV workloads
22:14:58 <ihrachys> I am not sure I grasp... which switch does flood the VM port?
22:14:59 <kevinbenton> i'm confused about this
22:15:08 <kevinbenton> do they want promiscuous traffic?
22:15:49 <armax> kevinbenton: that’s my understanding
22:16:09 <ihrachys> oh
22:16:26 <kevinbenton> but the description says they don't want it to improve performance
22:16:32 <armax> hang on
22:16:57 <armax> they mentioned about mac learning, which is this feature that the nsx plugin provides
22:17:11 <amotoki> I haven't grasped this.... nsx plugin maclearning extension is also mentioned. what does maclearnig ext do?
22:17:22 <ihrachys> maybe they mean that backends don't want to implement it globally for all ports, but just for those that users picked.
22:17:55 <armax> it’s like you want your VM’s to receive traffic for difference destination MACs
22:19:28 <amotoki> so, do we want to set vnic to promiscous mode selectively? it sounds reasonable
22:19:39 <ihrachys> I think it makes sense, but description would need some love. and I believe a write-up of how it's gonna be managed in ovs bridge would also help.
22:19:42 <armax> amotoki: that’s what I understand
22:19:51 <kevinbenton> yeah, i suppose promiscuous would be default then
22:19:54 <armax> ihrachys: right, this needs a full blown spec
22:20:03 <kevinbenton> i mean non-promiscuous
22:20:07 <armax> kevinbenton: right
22:20:10 <ihrachys> kevinbenton: you mean NON-promiscuous
22:20:13 <ihrachys> ok nevermind :)
22:20:15 <armax> kevinbenton: NON NON!!
22:20:28 <armax> kevinbenton: don’t confuse us further
22:20:42 <ihrachys> non non... double negation gives us...
22:20:53 <armax> ihrachys: NON. NON
22:21:01 <kevinbenton> yeah, i'm okay with proceeding with this
22:21:05 <armax> ok
22:21:09 <armax> then
22:21:44 <armax> let’s get to the next stage of spec definition
22:21:45 <armax> btw
22:21:49 <armax> I just remember something
22:22:21 <armax> for blueprint live-migration-portbinding
22:22:32 <armax> https://blueprints.launchpad.net/neutron/+spec/live-migration-portbinding
22:22:39 <armax> I wonder if I got the approver/assignee right
22:22:48 <armax> but I suppose I can reach out the folks directly
22:23:15 <armax> brianstajkowski1: ^
22:23:34 <ihrachys> yeah we probably need someone with +2 hammer for that
22:24:07 <armax> ihrachys: I don’t like the picture of that
22:24:20 <armax> ok, moving on
22:24:24 <armax> bug #1541895
22:24:24 <openstack> bug 1541895 in neutron "[RFE] [IPAM] Make IPAM driver a per-subnet pool option" [Wishlist,Triaged] https://launchpad.net/bugs/1541895
22:24:45 <ihrachys> armax: whack a mole
22:25:48 <ihrachys> ok, re ipam one, it makes sense, but the question is, who is going to implement it. I haven't seen infoblox folks active lately, and L3 subteam lost some diamonds lately..
22:25:57 <armax> ihrachys: yeah
22:26:01 <armax> that’s what I was thinking
22:27:22 <armax> We should involve haleyb as well as mlavalle to see if they have any interest in this one
22:27:34 <ihrachys> I generally want us to push back for proposals with no clear volunteers. so in this case, I would start with talking to the reporter and l3 subteam on whether they can give resources for that in next cycle. if not, we just postpone/Won't Fix for now.
22:27:51 <kevinbenton> yeah, i can see the use case but I'm not sure who would implement it
22:27:58 <armax> agreeed
22:28:17 <armax> ihrachys: we have marked this Incomplete once
22:28:19 <armax> we can do it again
22:28:34 <ihrachys> it's not incomplete, it's just maybe out of scope :)
22:28:43 <armax> rfe-deferred, then?
22:28:54 <ihrachys> the use case is clear, the proposal is ok, it just maybe doesn't fit
22:29:00 <armax> but in reality all RFEs are out of scope if they don’t have volunteers
22:29:04 <ihrachys> I am honestly lost in all RFE states
22:29:37 <amotoki> tend to agree. there seems use cases, but there are several choices on approaches...
22:30:00 <armax> once we agree that the use case is legit
22:30:17 <armax> then it’s a matter of finding a) who is gonna churn the code, and b) who is gonna review the code
22:30:24 <armax> but to start with we need a proper spec
22:30:43 <armax> and that means the balls goes back into belamaric’s court
22:32:35 <ihrachys> would be cool if we also make it clear that writing a spec without lining up resources won't get the effort much forward
22:32:45 <armax> ihrachys: true
22:32:50 <ihrachys> I saw a lot of specs written that don't happen
22:33:13 <armax> ihrachys: that can happen for all sorts of different reasons
22:33:44 <ihrachys> yea. I guess we have a path forward here?
22:33:47 <armax> good and bad
22:33:50 <armax> I think so
22:34:46 <armax> same goes with bug 1583694
22:34:46 <openstack> bug 1583694 in neutron "[RFE] DVR support for Allowed_address_pair port that are bound to multiple ACTIVE VM ports" [Wishlist,Triaged] https://launchpad.net/bugs/1583694 - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
22:35:07 <armax> that also needs a spec so that we can nail down on the way forward
22:35:32 <armax> but if we lack someone interested in pushing it forward, the use case, even though legit is never gonna go anywhere
22:36:56 <ihrachys> yes
22:37:13 <kevinbenton> we can revisit this one
22:37:21 <armax> bug #1592000
22:37:21 <openstack> bug 1592000 in neutron "[RFE] Admin customized default security-group" [Wishlist,Triaged] https://launchpad.net/bugs/1592000 - Assigned to Roey Chen (roeyc)
22:37:24 <kevinbenton> i may need to solve this for another use case that has come up
22:37:37 <armax> we’ve gone back and forth about this one
22:38:31 <armax> even though there’s no-one screaming for this, it looks like nova-net has/had this capability of customizing the default security group
22:38:52 <kevinbenton> armax: let's just do it then :)
22:39:01 <ihrachys> haha
22:39:13 <amotoki> :)
22:39:27 <njohnston> This is something we have definitely thought about having in FWaaS, although it is not there yet it's something I'll be shooting for in Pike.
22:39:52 <armax> my opionin still stand thoguh
22:39:54 <armax> though
22:39:55 <armax> https://bugs.launchpad.net/neutron/+bug/1592000/comments/5
22:39:55 <openstack> Launchpad bug 1592000 in neutron "[RFE] Admin customized default security-group" [Wishlist,Triaged] - Assigned to Roey Chen (roeyc)
22:39:55 <ihrachys> njohnston: consider how you are going to handle the compatibility issue expressed in bug comments
22:40:19 <armax> I am ok with the use case, I only wonder whether this should be FWaaS rather than security group as njohnston also pointed out
22:40:52 <armax> I am not convinced this should be crammed into the existing default security group semantic
22:40:59 <kevinbenton> https://review.openstack.org/#/c/287039/1/neutron/db/securitygroups_db.py
22:41:29 <njohnston> For FWaaS it's a special subset of the shared firewall policy model, that could be opted into by interested operators
22:41:39 <armax> kevinbenton: I should have -2 it
22:41:49 <kevinbenton> njohnston: but the vms will still have a default security group that doesn't allow anything though, no?
22:41:53 <armax> that’s an abomination
22:43:02 <kevinbenton> i thought you would like it :)
22:43:17 <njohnston> kevinbenton: Not necessarily.  Let's say an operator creates a shared firewall policy that allows ssh from a special sanctified jumphost but deny/deny for everything else, and that operator makes that the default security group for all new tenants that get made, I could see the use care for thaty
22:43:29 <armax> kevinbenton: creating a security group, stopping neutron-server, changing the config file and restarting the neutron-server (and all the replicas)? sure
22:43:48 <armax> that’s the greatest usability I have ever experienced
22:43:57 <kevinbenton> njohnston: oh, well if the operator is changing the default security group for each tenant
22:44:03 <kevinbenton> njohnston: then that makes sense
22:44:31 <kevinbenton> armax: I wrote that patch before neutron supported multiple servers :P
22:44:39 <armax> kevinbenton: that’s only 6 months old
22:44:41 <armax> don’t lie to me
22:44:53 <njohnston> this seems like an operator-serving feature more than a consumer of the operator's cloud-serving feature in any event because it happens on tenant creation
22:45:46 <armax> ok
22:46:02 <armax> after what njohnston said, it sounds to me that the way forward with this is to allow it with fwaas
22:46:26 <armax> I don’t think there’s any appetite to have this done with security groups
22:46:35 <armax> I certainly don’t have it
22:46:54 <armax> ihrachys, amotoki, kevinbenton?
22:47:01 <ihrachys> again, even in context of fwaas, you should think about how you make your api users detect the operator opted in the model
22:47:08 <armax> ihrachys: agreed
22:47:14 <amotoki> I am not sure that combination of SG and FWaaS helps the situation...
22:47:15 <njohnston> ihrachys: agreed
22:47:15 <armax> but we can make figure that out on a spec
22:47:33 <ihrachys> armax: I can't see a correct way to make it for security groups, as stated in comments; maybe fwaas is different, but I lack details.
22:48:03 <amotoki> it seems what the reportor wants is they just want to provide more convenient default rules.
22:48:17 <armax> amotoki: right, but that has problems
22:48:36 <amotoki> yes, interoperability issue :(
22:48:38 <armax> there’s a difference between what a single desires and the benefit for everybody else involved in the community :)
22:49:46 <armax> ok
22:51:29 <armax> moving on
22:51:32 <amotoki> even though we keep SG API compatibility, if operators applies FWaaS rules by default, filtering behavior will no longer compatible across clouds....
22:51:51 <armax> amotoki: but we can figure out ways in which that can be detected
22:52:20 <armax> retrofitting this on the security group well established behavior would be a lot more painful
22:52:28 <ihrachys> armax: retroactively? not sure.
22:52:43 <ihrachys> but I think it's a separate discussion; we decided it's not secgroup thing.
22:53:14 <armax> ihrachys: yes, that would be my take
22:54:12 <amotoki> yes, it is a different topic. anyway I agree that changing the current security group behavior is confusing.
22:55:29 <armax> I dropped for a sec
22:55:30 <armax> you guys can still see me?
22:55:30 <armax> yello?
22:55:57 <kevinbenton> hi
22:56:01 <ihrachys> yea
22:56:01 <amotoki> o/
22:56:10 <armax> ok
22:56:15 <armax> let see if we can squeeze
22:56:17 <armax> bug #
22:56:22 <armax> bug 1605343
22:56:22 <openstack> bug 1605343 in neutron "[rfe] update CIDR for subnet" [Wishlist,Triaged] https://launchpad.net/bugs/1605343 - Assigned to Vladimir Eremin (yottatsa)
22:56:35 <armax> I was close to rejecting this once
22:56:49 <armax> I am inclined to reject it agian
22:56:50 <armax> gain
22:56:52 <armax> again!
22:57:29 <ihrachys> shrinking definitely won't happen
22:57:50 <ihrachys> as for expansion, Vladimir has an uncovered use case in comment 8
22:58:25 <armax> I think that was in response to my comment of adding another subnet
22:58:28 <armax> to the lot
22:58:40 <armax> but that would need to happen in such as way that they do not overlap
22:58:41 <amotoki> comment 8 sounds a different story..
22:58:49 <armax> which I think it’s what already happens
22:59:32 <armax> we’re at time
22:59:40 <armax> let’s continue the discussion on the bug report
23:00:04 <armax> #endmeeting