22:02:27 <kevinbenton> #startmeeting neutron_drivers
22:02:28 <openstack> Meeting started Thu Mar 16 22:02:27 2017 UTC and is due to finish in 60 minutes.  The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:02:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:02:31 <openstack> The meeting name has been set to 'neutron_drivers'
22:02:37 <ihrachys> it's 3pm outside, and I am still working. disgusting.
22:02:44 <kevinbenton> ihrachys: we'll try to be quick :)
22:02:54 <ihrachys> kevinbenton: maybe moving it for earlier?
22:03:12 <armax> ihrachys: ah! I knew it
22:03:12 <kevinbenton> ihrachys: yes, this timeslot was mainly for amotoki
22:03:21 <ihrachys> amotoki is no longer?
22:03:30 <kevinbenton> ihrachys: we can maybe go to early morning for him
22:03:54 <kevinbenton> ihrachys: he's still around. i was just saying we can't just go earlier in the day without going much earlier
22:03:59 <kevinbenton> ihrachys: otherwise he definitely won't make it
22:04:42 <kevinbenton> armax: are you able to make an early morning meeting?
22:04:52 <kevinbenton> armax: on thursdays?
22:04:52 <armax> kevinbenton: depends how early
22:04:55 <ihrachys> I am up from 8am so you consider
22:04:59 <ihrachys> from 6am sorry
22:05:05 <armax> ihrachys: get out of town
22:05:08 <ihrachys> see? I can't make sense that late
22:05:19 <armax> my calendar is a mess right now
22:05:30 <armax> but generally after 9 is best for me
22:05:30 <kevinbenton> let me reach out to akihiro to see what times work for him
22:05:38 <kevinbenton> 9 might be a bit too late
22:05:41 <ihrachys> thanks
22:05:48 <kevinbenton> #action kevinbenton to reschedule drivers meeting
22:06:01 <kevinbenton> any announcements before we dig into RFEs?
22:06:33 <kevinbenton> ok
22:06:34 <armax> kevinbenton: you’re the announcer, no?
22:06:47 <kevinbenton> armax: i meant from you or ihrachys or anyone else
22:06:49 <kevinbenton> i don't have anything
22:07:13 <kevinbenton> ok
22:07:14 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe-approved
22:07:16 <armax> OK, I am working on the Pike stadium assessment, bear with me while I put something together
22:07:25 <kevinbenton> ack
22:08:11 <kevinbenton> sorry
22:08:15 <kevinbenton> link should be https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:08:16 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:09:10 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1476527
22:09:10 <openstack> Launchpad bug 1476527 in neutron "[RFE] Add common classifier resource" [Wishlist,Triaged] - Assigned to Igor Duarte Cardoso (igordcard)
22:09:16 <kevinbenton> armax: do you know the state of that one?
22:09:20 <armax> no
22:09:29 <kevinbenton> armax: it's still being done in a separate repo, no?
22:09:34 <armax> it’s largely autonomous
22:09:38 <armax> yes
22:09:41 <ihrachys> going from top? flow classifier, should we approve that and follow up on spec that is already proposed?
22:09:48 <ihrachys> igordcard checked with me on ptg, he is actively working
22:10:01 <kevinbenton> yeah, i'm for moving to approved
22:10:06 <ihrachys> +
22:10:10 <kevinbenton> we have someone working on it
22:10:21 <kevinbenton> and a way for it to be done non-disruptively
22:10:33 <ihrachys> elaborate on that
22:10:38 <ihrachys> they have their own repo
22:10:45 <kevinbenton> ihrachys: well it's being built in a separate repo
22:10:55 <kevinbenton> ihrachys: it's not going to break a bunch of stuff as they implement it is what i mean
22:11:14 <ihrachys> yeah, I think we should just review the design of the API and otherwise go out of their way
22:11:30 <ihrachys> if they deliver what they will write up, good
22:11:34 <kevinbenton> armax: any objections ?
22:12:16 <armax> nope
22:12:19 <ihrachys> which may mean we should give them some freedom in terms of reviews and permissions for the repo
22:12:24 <ihrachys> so that they can make progress
22:12:32 <ihrachys> ofc after spec agrement
22:12:41 <kevinbenton> ihrachys: sounds good
22:12:47 <kevinbenton> ihrachys: want to change the state?
22:12:55 <ihrachys> ok
22:13:30 <armax> ihrachys: which repo?
22:14:14 <ihrachys> armax: neutron-classifier
22:14:29 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1583096
22:14:29 <openstack> Launchpad bug 1583096 in neutron "[RFE] ml2 supported extensions list is inaccurate" [Wishlist,Triaged]
22:14:40 <armax> ihrachys: they already have full access, don’t they?
22:14:55 <kevinbenton> the comment at the end of this bug is a link to the same bug
22:15:06 <kevinbenton> armax: were you trying to crash human parsers?
22:15:07 <ihrachys> armax: could be, need to check. maybe igordcard doesn't
22:15:30 <ihrachys> I assumed it's Sean Collins and mostly that's it
22:15:49 <armax> ihrachys: ack
22:15:52 * armax checks
22:16:13 <armax> https://review.openstack.org/#/admin/groups/1184,members
22:16:19 <armax> we need to open up the circle
22:16:48 <armax> kevinbenton: yes
22:16:49 <armax> my bad
22:16:57 <armax> I am doing lots of unforced errors lately
22:17:02 <armax> just like a bad tennis match
22:17:17 <ihrachys> kevinbenton: re that ml2 bug, I think we had something specific for qos for that matter
22:17:20 * ihrachys looks
22:17:22 <kevinbenton> i think we should just roll https://bugs.launchpad.net/neutron/+bug/1583096 into the work being done for https://bugs.launchpad.net/neutron/+bug/1673142
22:17:22 <openstack> Launchpad bug 1583096 in neutron "[RFE] ml2 supported extensions list is inaccurate" [Wishlist,Triaged]
22:17:23 <openstack> Launchpad bug 1673142 in neutron "[RFE][ML2] Enforce extension semantics" [Wishlist,Confirmed]
22:17:38 <kevinbenton> the latter RFE is the work we discussed last week
22:18:21 <kevinbenton> so i'm going to mark 1583096 as dup of the newer one since that's the proposal I would like to see
22:18:23 <ihrachys> I talk about https://review.openstack.org/#/c/253853/
22:19:02 <ihrachys> actually seems like it's quite generic
22:19:13 <armax> ack
22:19:15 <armax> makes snese
22:19:34 <ihrachys> + on dup
22:20:49 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1628627
22:20:49 <openstack> Launchpad bug 1628627 in neutron "In FWaaS, when someone makes a change to a firewall rule we know, Who, What, When, and Where" [Wishlist,Triaged]
22:21:37 <armax> as for that one, if we don’t have anyone working on the fwaas team
22:21:44 <armax> might as well put it on the backburner
22:22:31 <kevinbenton> do we need an implementor before approving it?
22:22:44 <kevinbenton> if someone is looking to get into fwaas this might be a good feature to start with
22:22:49 <ihrachys> I would think yes, otherwise we fre-postponed?
22:22:56 <kevinbenton> ok
22:23:18 <ihrachys> would make sense to reach them to see if they are interested
22:23:25 <kevinbenton> i will leave a comment
22:23:48 <ihrachys> at this point I would expect fwaas team to focus on stabilizing/completing what they already have
22:24:32 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1630832
22:24:32 <openstack> Launchpad bug 1630832 in neutron "[RFE] FWaaS: Using Netlink instead of conntrack-tools to improve performance" [Wishlist,Triaged]
22:24:41 <kevinbenton> I think we can switch this one to approved
22:24:53 <kevinbenton> it needs some code cleanups that are being worked on
22:24:58 <armax> do you know who is going to work on i?
22:25:00 <kevinbenton> but there is nothing fundamentally wrong with the idea
22:25:00 <armax> it?
22:25:18 <kevinbenton> yeah, Ha Van Tu is working on it
22:25:29 <kevinbenton> patches already went in once
22:25:35 <kevinbenton> we reverted because they had some stability issues
22:25:47 <armax> I see
22:25:47 <kevinbenton> and Cedric has been helping out stabalize it
22:26:23 <kevinbenton> any issues with me marking it as approved?
22:26:56 <armax> no
22:27:00 <ihrachys> no
22:27:08 <kevinbenton> armax: what is the state machine for approved?
22:27:13 <ihrachys> not even sure why it's RFE :)
22:27:18 <kevinbenton> armax: remove rfe tag and add rfe-approved?
22:27:25 <kevinbenton> armax: set to confirmed?
22:27:30 <armax> OK
22:27:35 <kevinbenton> armax: sacrifice a goat?
22:27:35 <armax> I’ll create a BP for it
22:27:55 <ihrachys> kevinbenton: https://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
22:28:21 <kevinbenton> ihrachys: i can't read :'(
22:28:27 <ihrachys> #sad
22:28:58 <kevinbenton> ok
22:29:07 <armax> this is basically just using privsep though right?
22:29:11 <kevinbenton> based on that we do remove the 'rfe' tag and add 'rfe-approved' right?
22:29:31 <kevinbenton> armax: well it requires privsep
22:29:35 <armax> if there are no API or architectural changes
22:29:44 <kevinbenton> yeah, nothing visible to the user
22:29:44 <armax> we might as well treat it as a regular bug
22:29:47 <ihrachys> kevinbenton: yes, though I + the question from armax, not sure why the team cannot make the judgement themselves.
22:29:53 <kevinbenton> it's replacing shelling out to conntrack
22:30:03 <armax> with no BP involved
22:30:05 <kevinbenton> with netlink calls
22:30:18 <armax> I guess this was made RFE to err on the side of caution
22:30:26 <kevinbenton> yeah, it's a relatively large chunk of code
22:30:31 <armax> but if there’s nothing user facing, with minimal deployment impact
22:30:38 <armax> might as well be treated as a regular bug fix
22:30:39 <kevinbenton> so it's somewhat invasive and needs effort to merge
22:30:45 <dasm> how this rfe is different from ongoing efforts? https://etherpad.openstack.org/p/neutron-ocata-privsep
22:30:57 <kevinbenton> dasm: this depends on privsep
22:31:09 <kevinbenton> dasm: it's a particular privileged operation that will execute in a privsep context
22:31:38 <armax> I’d say let’s track it as any other bug
22:31:41 <dasm> isn't this similar to this? https://bugs.launchpad.net/neutron/+bug/1492714
22:31:41 <openstack> Launchpad bug 1492714 in neutron "RFE: Pure Python driven Linux network configuration" [Wishlist,In progress] - Assigned to Omer Anson (omer-anson)
22:32:06 <kevinbenton> dasm: that's another thing that would depend on privsep
22:32:09 <armax> dasm: true, but that was more open ended
22:32:13 <kevinbenton> dasm: using pyroute2 library
22:32:23 <kevinbenton> dasm: this is particularly for conntrack calls
22:32:26 <dasm> ack
22:32:26 <kevinbenton> dasm: https://review.openstack.org/#/c/437311/5/neutron_fwaas/privileged/netlink_lib.py
22:32:36 <kevinbenton> it's not particularily trivial
22:33:00 <armax> btw does anyone now what is left for closing bug 1492714?
22:33:01 <openstack> bug 1492714 in neutron "RFE: Pure Python driven Linux network configuration" [Wishlist,In progress] https://launchpad.net/bugs/1492714 - Assigned to Omer Anson (omer-anson)
22:33:12 <kevinbenton> i think it needs to be implemented :)
22:33:17 <ihrachys> armax: I think it's pretty much everything
22:33:22 <ihrachys> we converted a single function
22:33:27 <ihrachys> that is not even used in production code
22:33:30 <ihrachys> tests only
22:33:33 <armax> oh boy
22:33:53 <dasm> armax: Brian Haley started doing that. this one was first attempt,  but got abandoned: https://review.openstack.org/#/c/155631/
22:33:55 <kevinbenton> :)
22:34:05 <kevinbenton> yeah, we have the scaffolding in place now so-to-speak
22:34:14 <kevinbenton> we just need to start switching to pyroute2 calls
22:34:32 <ihrachys> kevinbenton: I think there is agreement it's fine to give conntrack thingy a go, so let's approve, bug or RFE and let them move on
22:34:45 <armax> aye aye
22:34:46 <kevinbenton> ihrachys: yep. armax approved
22:34:49 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1630981
22:34:49 <openstack> Launchpad bug 1630981 in neutron "[rfe] Implement l2pop driver functionality in l2 agent" [Wishlist,Triaged]
22:34:58 <kevinbenton> I would like to see this go in
22:35:08 <kevinbenton> I can help with vxlan termination info going into binding
22:35:31 <kevinbenton> Anil had started on working on mac address lookups from port info on the agent side
22:36:11 <kevinbenton> once we are referencing the port OVO for mac addresses and tunnel endpoints, l2pop can be shut off
22:36:26 <ihrachys> + let's do it. a separate driver didn't make much sense ever.
22:36:36 <ihrachys> and we have someone poking it
22:36:53 <armax> kevinbenton: question
22:36:59 <kevinbenton> also one of the most important performance impacts is the stupid state machine the agent puts the ports through when it restarts to trigger the l2pop code
22:37:06 <armax> can the new solution and the l2pop driver coexist?
22:37:09 <kevinbenton> ACTIVE->BUILD->ACTIVE
22:37:30 <kevinbenton> armax: yes
22:37:36 <ihrachys> armax: for what? external consumers for RPC?
22:37:53 <kevinbenton> armax: it will need to for backward compat between agent types at a minimum
22:38:05 <armax> I mean, can deployments still keep l2pop on the list of mech drivers?
22:38:11 <kevinbenton> armax: yes
22:38:16 <armax> OK, I think this needs a spec
22:38:18 <armax> IMO
22:38:54 <ihrachys> armax: keeping it a shallow no-op, or actually notifying?
22:39:02 <ihrachys> + for the spec and we can proceed discussion there
22:39:07 <armax> to capture some of the challenges that required to get this implemented
22:39:32 <armax> I am in favor of nuking l2pop
22:39:44 <armax> but I do know that we need to figure out a graceful way to do it
22:39:52 <armax> out of tree projects may rely on it
22:40:04 <kevinbenton> armax: i don't intend on touching the driver
22:40:16 <kevinbenton> armax: but we should deprecate and remove it
22:40:27 <kevinbenton> armax: at some point
22:40:36 <armax> I understand
22:40:48 <ihrachys> or allow to move it somewhere outside if there are interested parties
22:40:53 <armax> I wonder if the two will clash together if used in teh context of the same deployment
22:40:58 <armax> but we can discuss this on the spec
22:41:09 <kevinbenton> armax: no, new agents will ignore l2pop messages
22:41:15 <kevinbenton> sure
22:41:22 <kevinbenton> mark that it needs a spec
22:41:28 <armax> kevinbenton: right, that’s assumed you did the work correctly ;)
22:41:40 <armax> kevinbenton: aye sir
22:41:46 <kevinbenton> armax: discussing bugs isnt' really what a spec is for :)
22:42:04 <armax> you’d be surprised
22:42:17 <kevinbenton> i think the difficult part is actually going to be the DB migration
22:42:20 <armax> how many feature requests are disguised as bug reports
22:42:58 <kevinbenton> ihrachys: i will probably need your help figuring out a way to deal with that
22:43:08 <ihrachys> noted
22:43:21 <kevinbenton> ihrachys: new servers may need to dynamically calculated the null column before returning data
22:43:23 <armax> #action armax to approve rfe 1630981
22:43:25 <kevinbenton> ihrachys: so a getter would have a setter
22:43:56 <kevinbenton> or always dynamically calculate until a switchover is performed
22:44:04 <kevinbenton> we'll discuss on spec
22:44:04 <armax> and a setter would have a getter?
22:44:35 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1632877
22:44:35 <openstack> Launchpad bug 1632877 in neutron "[RFE] Limits and Counts for SecGroup and FIPs" [Wishlist,Triaged] - Assigned to Prince Nana Owusu Boateng (nanaboat)
22:45:25 <kevinbenton> there is a patch up for this
22:45:31 <armax> if we mirror this just as the effort for IP capacity
22:45:38 <kevinbenton> i don't have a link handy, but it seems reasonable
22:45:45 <armax> kevinbenton: find it!
22:45:49 <kevinbenton> armax: it's not even that complicated
22:45:51 <ihrachys> kevinbenton: would be nice to see it in LP
22:45:58 <armax> kevinbenton: agreed
22:45:59 <ihrachys> kevinbenton: that's a separate API?
22:46:00 <kevinbenton> it's just to ask for things that the quota engine arleady knows
22:46:08 <kevinbenton> part of quota api
22:46:21 <armax> OK, I’ll process this once you give me the patch #
22:46:38 <kevinbenton> https://review.openstack.org/#/c/383673/
22:46:54 <armax> https://review.openstack.org/#/c/383673/34/neutron/plugins/ml2/plugin.py
22:46:57 <armax> nooooooooooooo
22:47:20 <ihrachys> :))
22:47:22 <armax> https://review.openstack.org/#/c/383673/34/neutron/extensions/quotasv2_detail.py
22:47:25 <armax> nooooooooooooooooooo
22:47:31 <kevinbenton> provide patch feedback
22:47:31 <bzhao_> /
22:47:41 <kevinbenton> this doesn't have to do with the rfe though :)
22:47:46 <armax> agreed
22:47:52 <armax> I’ll get this straigthen out
22:48:41 <ihrachys> so + on the RFE?
22:48:50 <armax> yes, we need an approver though
22:49:01 <kevinbenton> i can be approver for that
22:49:11 <armax> this is going to be a BP
22:49:17 <asingh_> https://review.openstack.org/#/c/348947/  this is the neutron spec for above patch
22:49:21 <armax> kevinbenton: do you know what you’re doing
22:49:22 <armax> ?
22:49:34 <armax> asingh_: thanks!
22:49:37 <kevinbenton> no
22:49:58 <armax> kevinbenton: good
22:50:00 <armax> let’s move on
22:50:39 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1633280
22:50:39 <openstack> Launchpad bug 1633280 in neutron "[RFE]need a way to disable anti-spoofing rules and yet keep security groups" [Wishlist,Triaged]
22:50:44 <armax> oh that
22:51:11 <armax> Even though I can see how this can be implemented
22:51:18 <armax> I don’t fully understand the use case presented
22:52:37 <kevinbenton> wouldn't allowed address pairs work?
22:52:46 <kevinbenton> just allow 0.0.0.0/0
22:53:23 <kevinbenton> left a comment
22:53:31 <kevinbenton> let's revisit that one next week when they respond
22:53:35 <armax> kevinbenton: ok
22:53:49 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1639566
22:53:49 <openstack> Launchpad bug 1639566 in neutron "[RFE] Add support for local SNAT" [Wishlist,Triaged]
22:54:16 <kevinbenton> I would like to see something done here
22:54:20 <armax> I don't
22:54:40 <ihrachys> I have no opinion since first time I see it
22:54:49 <armax> this will crash and burn and we have no luxury to throw resources at the problem IMO
22:54:53 <kevinbenton> ihrachys: essentially parity with nova network
22:55:00 <kevinbenton> ihrachys: direct routing for snat as well
22:55:11 <ihrachys> distributed dvr_snat?
22:55:22 <armax> ihrachys: correct
22:55:44 <armax> we kissed this goodbye when we went down the path of DVR+HA
22:55:56 <armax> for SNAT
22:56:15 <kevinbenton> not really
22:56:19 <kevinbenton> they aren't related
22:56:32 <armax> I see no reason on working on this now
22:56:48 <armax> after all the many years we talked about this very topic
22:56:57 <kevinbenton> do you know why people keep asking for it?
22:57:24 <armax> that’s not the point
22:57:32 <armax> just because people ask, you don’t just do
22:58:07 <armax> people can be educated in doing the right thing :)
22:58:09 <kevinbenton> it sounds to me like the reason we're not doing it is because of existing technical debt
22:58:16 <armax> no
22:58:18 <armax> that’s not it
22:58:29 <armax> I think https://etherpad.openstack.org/p/decentralized-snat is emblematic
22:58:58 <armax> and it was initiatd in 2014
22:59:04 <ihrachys> l3 solution already has a lot of moving parts and deployment options that we ourselves struggle to maintain (consider gate state for all those multinode tempest jobs), so I see why armax is concerned.
22:59:23 <kevinbenton> right, so tech debt
22:59:45 <armax> of all the technical solutions proposed
22:59:57 <armax> that one was not identified, time and time again, as the best compromise
23:00:05 <armax> so I don’t understand why we keep coming back to it
23:00:10 <armax> to me the case is closed, frankly
23:00:26 <kevinbenton> because all of the other solutions don't solve a problem
23:00:38 <armax> we’re at time
23:00:40 <kevinbenton> and that is no centralized routing for SNAT
23:00:46 <kevinbenton> #endmeeting