22:00:42 <kevinbenton> #startmeeting neutron_drivers
22:00:43 <openstack> Meeting started Thu May 25 22:00:42 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:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:45 <ihrachys> o/
22:00:46 <openstack> The meeting name has been set to 'neutron_drivers'
22:01:44 <bzhao_> o/
22:01:57 <kevinbenton> does anyone have anything they would like to discuss with ongoing blueprint issues before we take a look at a couple of RFEs?
22:02:45 <ihrachys> no
22:02:54 <armax> none from me
22:03:06 <mlavalle> i'm good
22:03:17 <kevinbenton> ok
22:03:19 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:03:38 <kevinbenton> i'm going to go out of order initially because there are a few that we've discussed before and we should be able to quickly approve
22:03:51 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1673142
22:03:53 <openstack> Launchpad bug 1673142 in neutron "[RFE][ML2] Enforce extension semantics" [Wishlist,Triaged]
22:03:53 <armax> ok
22:04:07 <kevinbenton> this was discussed at the PTG and I don't think anyone had any issues with it
22:04:27 <kevinbenton> it's also needed to cleanup some custom validation logic that is getting sprinkled everywhere for QoS and now SG logging
22:04:32 <ihrachys> authors lined to pull it?
22:05:01 <armax> no, I think this makes sense
22:05:14 <kevinbenton> I think Bob said he has some time to work on it
22:05:15 <armax> not sure if there’s any sane implementation
22:05:32 <ihrachys> good. if we have Bob committed, this should def go in
22:06:07 <kevinbenton> I think we can move to approved and if Bob can't get it done this cycle it can defer later
22:06:18 <armax> aye
22:06:32 <ihrachys> +
22:06:32 <mlavalle> ++
22:07:57 <kevinbenton> actually that might have been the only one i needed to do out of order
22:08:33 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1042049
22:08:34 <openstack> Launchpad bug 1042049 in neutron "[RFE] auto-associate floating ips" [Wishlist,Triaged]
22:08:53 <mlavalle> we lost this one almost 5 years...
22:08:57 <armax> this was brought up at the summit
22:08:57 <kevinbenton> this thing is a little old :)
22:09:01 <armax> in the forum
22:09:09 <armax> discussion about get-me-a-network
22:09:12 <ihrachys> heh
22:09:14 <armax> I ended up fishing through the pile
22:09:16 <armax> :)
22:09:20 <ihrachys> yeah, it will fit auto-allocated-net
22:09:39 <kevinbenton> armax, do you have the bandwidth to work on this one?
22:09:41 <ihrachys> so operators feel like wasting fips?
22:09:51 <kevinbenton> ihrachys: yep
22:10:48 <kevinbenton> we would obviously need to figure out how discoverability of this behavior and whatnot will work
22:11:08 <clarkb> fwiw this is shades default behavior when creating an instance unless you tell it to do something different
22:11:50 <kevinbenton> and it's also how EC2 works IIRC
22:11:58 <kevinbenton> or how it did many a year ago :)
22:12:15 <ihrachys> hm, I think elastic ip should be explicitly assigned there, but... doesn't matter
22:12:58 <kevinbenton> i think i see two components here
22:13:26 <kevinbenton> one is a flag that can be set on a network that causes any ports to get a floating IP that are created on that network
22:13:52 <kevinbenton> the other is adjusting the auto allocated topology to set that flag
22:14:17 <kevinbenton> armax: there?
22:15:45 <mlavalle> we lost him
22:16:01 <mlavalle> i'm afraid
22:16:03 <kevinbenton> yeah
22:16:06 <kevinbenton> looks that way
22:16:47 <mlavalle> but the network flag could me used independently of auto allocated topology, right?
22:16:52 <kevinbenton> yes
22:16:53 <mlavalle> be used^^^
22:16:56 <kevinbenton> I think so
22:17:14 <armax> sorry
22:17:26 <kevinbenton> I believe we will need to track when floating IPs are auto allocated as well and auto release them
22:17:28 <ihrachys> so on router attach, it will assign a fip per tenant port?
22:18:14 <kevinbenton> ihrachys: good question. not sure if it should affect existing ports or if we should even allow the flag to be set without a router already attached
22:18:16 <ihrachys> we'll need to allocate a bunch of fips at once.
22:18:29 <armax> I am back
22:18:38 <mlavalle> I think kevinbenton's approach is safer
22:18:59 <kevinbenton> armax: do you have bandwidth to work on this feature?
22:19:15 <ihrachys> anyhoo, I think we can leave it to drafter to write it up, and then we can beat it to death. assuming we have a drafter.
22:19:18 <armax> kevinbenton: this work is independent from the auto-allocated-topology effort
22:19:25 <armax> to start with anyway
22:19:36 <armax> kevinbenton: I can try and put some cycles for a spec
22:19:40 <armax> as I feel it’s needed
22:19:42 <kevinbenton> armax: yeah, did you see my messagers early up?
22:19:48 <kevinbenton> messages*
22:19:49 <armax> I am scrolling up
22:20:06 <kevinbenton> the flag on the network that controls auto allocation is the biggest component
22:20:16 <kevinbenton> and is orthoganal to get-me-a-network
22:20:22 <kevinbenton> ok
22:20:26 <kevinbenton> well if you can write a spec
22:20:27 <armax> OK, let me flush out a spec and associated it to this
22:20:29 <kevinbenton> lets approve
22:20:39 <armax> I think this makes sense
22:20:39 <ihrachys> +
22:20:50 <armax> not sure why it got buried in the pile
22:20:53 <mlavalle> ++, will make Dan's dream reality after 5 years
22:20:58 <armax> and why it was never considered a nova-net feature parity gap
22:21:22 <ihrachys> first rule of neutron club - never talk about new parity gaps
22:21:35 <mlavalle> ihrachys: you got it!
22:21:40 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1505627
22:21:42 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee)
22:21:55 <kevinbenton> mlavalle: did the qos team chat about this?
22:22:09 <mlavalle> I brought this up during the meeting on Tuesday
22:22:23 <mlavalle> ralonsoh said he was going to connect tonight
22:22:38 <mlavalle> but I don't see him around
22:22:47 <ihrachys> what was the general feeling? or there was no actual discussion?
22:23:00 <mlavalle> he mostly said it was reedip's stuff
22:23:18 <mlavalle> and reedip inidcated he wants to pursue it
22:23:52 <mlavalle> not something that the entire QoS jumped and supported enthusiastically
22:23:56 <ihrachys> people indicate a lot of things :)
22:24:01 <ihrachys> just sayin
22:24:06 <mlavalle> agree
22:24:15 <kevinbenton> maybe we should allow reedip to write a spec so we can get all of the implementation questions answered?
22:24:18 <mlavalle> doesn't seem high in their priorities
22:24:33 <kevinbenton> or just defer
22:24:37 <kevinbenton> until next cycle
22:24:45 <mlavalle> kevinbenton: let's give reedip the opportunity
22:24:55 <kevinbenton> ok
22:25:05 <ihrachys> I would rather not spend time (and I won't). I don't see it is critical for reedip either.
22:25:10 <ihrachys> anyhoo, you are free to
22:25:54 <mlavalle> well, let's mark it deferred and let reedip come back to us if it is that important
22:26:13 <kevinbenton> mlavalle: ok
22:27:10 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1506076
22:27:11 <openstack> Launchpad bug 1506076 in neutron "Allow connection tracking to be disabled per-port" [Wishlist,Triaged]
22:28:33 <armax> this to me sounds like it requires no user facing changes
22:28:43 <armax> I wonder if it can be treated as a regular bug
22:28:46 <kevinbenton> yes
22:28:49 <kevinbenton> armax: i agree
22:29:07 <kevinbenton> this is about figuring how how to tell the firewalls not to conntrack a security disabled port
22:30:06 <ihrachys> so just a terminating iptables rule? yes, it's a performance optimization, nothing to RFE
22:30:29 <kevinbenton> yep, and changing the CT action rules in ovs native firewall if necessary
22:31:01 <ihrachys> + on moving from RFE to bug
22:31:19 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1518392
22:31:21 <openstack> Launchpad bug 1518392 in neutron "[RFE] Enable arp_responder without l2pop" [Wishlist,Triaged] - Assigned to Kevin Benton (kevinbenton)
22:31:58 <armax> kevinbenton: I assigned this to you
22:32:06 <kevinbenton> so this is referring to one of the many roles of l2pop
22:32:09 <armax> yea
22:32:28 <kevinbenton> right now in addition to populating forwarding entries for tunnels
22:32:42 <kevinbenton> it's messages are also used to setup ARP responder entries
22:33:15 <kevinbenton> However, we can setup ARP responder entries using just the existing port update messages that go to the l2 agent
22:33:38 <ihrachys> vif_details included?
22:33:48 <kevinbenton> ihrachys: what do you mean?
22:34:03 <ihrachys> sorry, mixed things, thought about tunnels.
22:34:10 <ihrachys> yeah right, you have mac addr there
22:34:53 <kevinbenton> So I would like to approve this, but I won't be able to work on it right away and it might slip to next cycle
22:35:03 <kevinbenton> depending on how the push notifications stuff goes
22:35:06 <ihrachys> that's ok I believe
22:35:11 <mlavalle> yeah
22:35:14 <kevinbenton> i still need to get SGs fixed up for push notifications
22:35:24 <ihrachys> well ovs piece is in gate
22:35:33 <mlavalle> yeap
22:35:41 <kevinbenton> ihrachys: that's only for basic l2 things
22:35:50 <kevinbenton> ihrachys: i have an abandoned patch i need to restore for the SG component
22:36:04 <ihrachys> what else do you need for arp responder?
22:36:11 <kevinbenton> nothing else
22:36:18 <kevinbenton> just bandwidth to actually implement it :)
22:36:27 <ihrachys> ok ok, I am just saying no dep
22:36:30 <ihrachys> anymore
22:36:31 <kevinbenton> yep
22:36:32 <kevinbenton> no deps
22:37:07 <ihrachys> + let's approve
22:37:18 <kevinbenton> cool
22:37:20 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1640956
22:37:22 <mlavalle> ++
22:37:23 <openstack> Launchpad bug 1640956 in neutron "RFE: Extension for improving Nova-Neutron callflow to cache port data" [Wishlist,Triaged]
22:38:09 <ihrachys> was there ever a write-up for neutron side?
22:38:28 <kevinbenton> I don't think so
22:38:33 <ihrachys> or alternatively, was Ian at PTG and assured he will pull it?
22:38:49 <kevinbenton> Ian was at the PTG and he said he had resources for this
22:39:07 <kevinbenton> I'm okay with the high-level of having an API call for all things related to a port
22:39:11 <kevinbenton> it's floating ips
22:39:19 <kevinbenton> its subnets, networks, etc
22:39:22 <ihrachys> trunks
22:39:25 <kevinbenton> ++
22:39:30 <ihrachys> yes I think I agree with the general idea
22:39:32 <kevinbenton> so i'm thinking we can just approve this and wait for the spec
22:39:44 <mlavalle> ok
22:40:18 <armax> kevinbenton: or do we want to wait for the spea
22:40:20 <armax> spec
22:40:26 <armax> before approval?
22:40:40 <kevinbenton> no
22:40:50 <kevinbenton> i want to say the enhancement i agree with
22:41:01 <kevinbenton> the rest is implementation details
22:41:30 <armax> ok
22:42:02 <ihrachys> you're the boss, go for it
22:42:09 <kevinbenton> in my mind 'rfe-approved' == valid use case we can address
22:42:26 <armax> well
22:42:27 <mlavalle> so spec is next step?
22:42:32 <kevinbenton> mlavalle: yep
22:42:36 <armax> rfe-approved meant more than that
22:43:01 <armax> it means it makes sense, we have a chance to make it happen
22:43:16 <kevinbenton> that's what i just said :)
22:43:17 <armax> in terms of resources both dev and review
22:43:20 <kevinbenton> oh
22:43:23 <kevinbenton> i see
22:43:34 <kevinbenton> i think those should be separate
22:43:44 <kevinbenton> and tracked via the corresponding blueprint and milestone tracking
22:43:59 <ihrachys> it's actually captured in devref, so maybe kevinbenton you can start with posting a patch for the docs? because it's not the first time confusion re process arises.
22:44:07 <armax> otherwise we can have a bunch of rfe approved and respective blueprints which we track but never go anywhere
22:44:35 <ihrachys> I lean to armax vision in that resources should be lined up prior to approval
22:44:36 <kevinbenton> armax: which is fine IMO because it shows where we need more resources
22:44:47 <armax> the idea behind the rfe process is that we can coordinate the effort in a way that we the team can have a sense of what is actually going to be delivered
22:44:48 <kevinbenton> i disagree
22:45:12 <kevinbenton> because it makes it hard for people that have the power to provide resources
22:45:19 <armax> otherwise, approve it all! and we can save an hour a week
22:45:28 <kevinbenton> to tell if there are legitimate features that aren't getting implemented because of a resource shortage
22:45:41 <kevinbenton> or if features are just being rejected because they dont' fit the proejct
22:45:44 <armax> right, that’s a problem we’re experiencing only recently
22:46:47 <armax> rfe’s don’t disappear
22:47:02 <armax> and we don’t need to reject them
22:47:16 <armax> so far we have been marking some incomplete
22:47:20 <armax> for one reason or another
22:47:29 <kevinbenton> ok, i'll file a devref change
22:47:29 <armax> at the end of each cycle we look at the rfe graveyard
22:47:33 <armax> wait
22:47:33 <ihrachys> in my experience, powers usually come to the table with their own features, it's not like there is spare pool of talent that sits there waiting for RFE to move to -approved.
22:47:36 <armax> I disagree with you
22:47:39 <armax> :)
22:47:54 <armax> I think you’re breaking the only thing that might work in this RFE process
22:48:18 <ihrachys> armax, you can still disagree in gerrit
22:48:19 <armax> we can take this on your devref change though
22:48:21 <armax> yeah
22:48:22 <armax> that’s fine
22:48:35 <armax> -2 coming right up
22:48:38 <armax> :)
22:49:01 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1640960
22:49:02 <openstack> Launchpad bug 1640960 in neutron "RFE: VIF plugging negotiation between Nova and Neutron" [Wishlist,Triaged]
22:49:33 <mlavalle> kevinbenton: i think I recall that we were going to discuss some of trevormc rfe's today
22:49:40 <mlavalle> per last meeting
22:49:58 <trevormc> sorry to interrupt, any chance we can get to at least this one (of three) https://bugs.launchpad.net/neutron/+bug/1693240 ?
22:49:58 <openstack> Launchpad bug 1693240 in neutron "[RFE] Support SRIOV VF VLAN Filtering" [Wishlist,Triaged]
22:50:57 <kevinbenton> trevormc: it's still not clear to me if you're requesting a Neutron API change here
22:51:12 <ihrachys> is it just sriov driver for trunks?
22:51:16 <kevinbenton> right
22:51:19 <trevormc> no api change should be required.
22:51:24 <kevinbenton> trevormc: ok
22:51:27 <kevinbenton> then I'm good with this
22:51:28 <ihrachys> if so, just post one as a bug no?
22:51:38 <kevinbenton> it's just a feature implementation gap in SR-IOV
22:51:52 <trevormc> we can query trunk ports to make a list and then use VFd to configure the nic.
22:52:03 <kevinbenton> ok
22:52:14 <trevormc> thanks, thats the only one i wanted reviewed
22:52:21 <kevinbenton> so this can just be treated as a regular bug like ihrachys said
22:52:31 <trevormc> ok
22:52:50 <ihrachys> remove rfe-* flags, it's not needed. leave Wishlist. no BP or spec.
22:53:00 <trevormc> got it
22:53:14 <kevinbenton> trevormc: and assign to yourself assuming you're writing the code :)
22:53:28 <trevormc> yep :)
22:53:31 <kevinbenton> ok
22:53:35 <mlavalle> we will come after you trevormc ;-)
22:53:40 <kevinbenton> let's see if we can cover https://bugs.launchpad.net/neutron/+bug/1640960
22:53:41 <openstack> Launchpad bug 1640960 in neutron "RFE: VIF plugging negotiation between Nova and Neutron" [Wishlist,Triaged]
22:54:19 <kevinbenton> this is another Ian said he had resources for and was pitching at the PTG
22:54:58 <ihrachys> I think the main question to answer here is how does it fit multiple port bindings plans, and whether we squash them into the same extension. or we want to deal with 3 binding extensions.
22:55:41 <kevinbenton> ihrachys: i think they are orthoganal and IMO multiple port bindings is more important so i don't want to drag that spec down fleshing this out as well
22:55:54 <kevinbenton> because there are dragons in the implementation details of this one
22:55:55 <ihrachys> as for implementation, it seems to be largely driven from nova side, so we will just accommodate.
22:56:12 <kevinbenton> (on the nova side)
22:56:20 <ihrachys> ok 3 extensions then. since they are admin, maybe it's not that bad.
22:56:52 <kevinbenton> yes
22:57:01 <kevinbenton> i doubt this will land on the nova side this cycle anyway
22:57:24 <kevinbenton> so we would probably be forced into another extension anyway
22:57:42 <kevinbenton> i said anyway too many times in a row :)
22:58:00 <armax> 3 minutes left, anyway
22:58:01 <ihrachys> so you want to approve but don't plan to land anything?
22:58:03 <armax> 2 now
22:58:09 <kevinbenton> approve and wait for spec
22:58:14 <kevinbenton> let nova folks drive the priority
22:58:19 <kevinbenton> because neutron side should be simple
22:58:33 <kevinbenton> basically pick from a list of vif types
22:59:06 <ihrachys> I guess we won't have problems with resources once it gets to it
22:59:46 <kevinbenton> ok, approved and waiting on spec then
22:59:53 <mlavalle> +
23:00:27 <armax> ok
23:00:29 <armax> time
23:00:34 <kevinbenton> #endmeeting