22:03:08 <kevinbenton> #startmeeting neutron_drivers
22:03:09 <openstack> Meeting started Thu Feb  9 22:03:08 2017 UTC and is due to finish in 60 minutes.  The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:03:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:03:13 <openstack> The meeting name has been set to 'neutron_drivers'
22:03:34 <haleyb> hi
22:03:46 <kevinbenton> armax, ihrachys: anything critical to the release we need to talk about first?
22:04:30 <armax> anything would be in here
22:04:32 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=ocata-rc-potential
22:05:03 <armax> there’s the PTG to talk about as well
22:05:06 <kevinbenton> ok, both of the critcals on there have patches in flight
22:05:18 <kevinbenton> yeah, PTG is something I want to talk about next
22:05:21 <ihrachys> but we can't land them, at least first one
22:05:35 <kevinbenton> ihrachys: why not?
22:05:58 <ihrachys> gate failures, I have no details what specifically fails
22:06:08 <kevinbenton> oh
22:06:09 <ihrachys> but it's a string of rechecks in gerrit basically
22:06:12 <ihrachys> https://review.openstack.org/#/c/429095/
22:06:13 <kevinbenton> right
22:06:29 <kevinbenton> i thought you meant something other than the recheck grind
22:06:40 <ihrachys> nah, 'just' that thing
22:06:47 <kevinbenton> :)
22:06:52 <kevinbenton> just the massive instability of the gate
22:07:11 <armax> it looks like the worker tweaks I made only helped so much
22:07:17 <kevinbenton> Other than that, how was the play, Mrs. Lincoln?
22:07:25 <ihrachys> http://www.themarysue.com/wp-content/uploads/2016/08/post-64231-this-is-fine-dog-fire-comic-Im-N7mp.png
22:08:13 <kevinbenton> so shall we talk about the PTG now?
22:08:49 <armax> let’s
22:08:51 <ihrachys> sure, why not. though I see we three are the only participants :-x
22:09:06 <kevinbenton> #topic PTG
22:09:23 <kevinbenton> we basically don't have scheduled meetings this time, right?
22:09:47 <ihrachys> we don't, but I believe it's still better to have a time table with main topics
22:10:01 <kevinbenton> yeah
22:10:01 <armax> kevinbenton: do you know there’s an openstack-ptg channel?
22:10:16 <kevinbenton> armax: no
22:10:21 <armax> now you do
22:10:38 <kevinbenton> armax: do we feed it the etherpad and it schedules it all for us?
22:10:40 <armax> only cool kids hang in there
22:11:01 <armax> I don’t think that’s what irc channels do
22:11:12 <kevinbenton> what is the purpose of it?
22:11:29 <kevinbenton> is it for PTG participants, organizers or what?
22:11:31 <ihrachys> "Discussion of the Project Teams Gathering and for use during the PTG for on-site announcements"
22:11:36 <ihrachys> you are welcome
22:12:03 <armax> http://lists.openstack.org/pipermail/openstack-dev/2017-January/110909.html
22:12:34 <kevinbenton> ok
22:13:07 <kevinbenton> ihrachys: you had an etherpad you started of the grouped topics, right?
22:13:16 <kevinbenton> ihrachys: do you want to put that here and talk about it?
22:13:17 <armax> as an attendee of the PTG I would expect some organization of the PTG days
22:13:42 <armax> do we know the room layout?
22:13:45 <ihrachys> yeah
22:13:48 <ihrachys> #link https://etherpad.openstack.org/p/neutron-ptg-pike-final
22:13:54 <ihrachys> despite the name, it's not final
22:14:00 <armax> whether we have separate tables etc?
22:14:06 <ihrachys> and people are welcome to help setting it up, and ripping it off
22:14:35 <armax> that’s a start
22:14:54 <ihrachys> yes, it needs love, and it does not cover logistics
22:15:00 <kevinbenton> armax: i'm not sure about the room layout. Should I ping Thierry to get that?
22:15:46 <armax> probably not necessary, I am sure there will be tables
22:15:55 <armax> :)
22:16:18 <armax> the layout can be made up on the fly if need be
22:16:27 <armax> though we don’t want to mess up with extension cords etc
22:17:27 <kevinbenton> well tables might be problematic if we want everyone to listen in
22:17:58 <armax> on this one
22:17:59 <armax> https://etherpad.openstack.org/p/neutron-ptg-pike-final
22:18:03 <armax> we lost the list of attendees
22:18:17 <ihrachys> I feel there is some leg work for kevinbenton to do. once we know the layout and setting, we can look if we e.g. can afford split discussions. now, we can talk about what's in the pad.
22:18:19 <kevinbenton> i think ihrachys disinvited them
22:18:24 <armax> and a link to the free format thingy
22:18:28 <ihrachys> armax: not necessarily lost, it's in the prev version
22:18:38 <haleyb> https://etherpad.openstack.org/p/neutron-ptg-pike
22:18:45 <ihrachys> I just haven't moved it
22:18:46 <kevinbenton> yeah, there are some of these that probably don't need everyone to pile on
22:19:10 <armax> there’s roughly 40 people signed up
22:19:11 <ihrachys> and kevinbenton may need to do another swipe through the old pad to make sure we captured all latest updates
22:19:12 <kevinbenton> we can schedule those concurrently with special projects meetups
22:19:24 <kevinbenton> yeah, i will carry stuff over
22:19:28 <armax> I wonder how big are the rooms
22:19:34 <kevinbenton> i'll wait until early next week to give a little more time
22:19:48 <armax> and whether we’ll be able to fit all in the same place
22:19:51 <kevinbenton> i know a few people just found out about the etherpad and were going to add a few points
22:20:16 <ihrachys> armax: what's the free format thingy?
22:20:25 <armax> https://etherpad.openstack.org/p/neutron-ptg-pike+
22:20:27 <armax> https://etherpad.openstack.org/p/neutron-ptg-pike
22:20:28 <ihrachys> og you mean back-ref to the old pad?
22:20:30 <ihrachys> ok
22:20:47 <kevinbenton> armax: you are planning on bailing Friday right?
22:21:28 <armax> I am out by lunch time
22:21:31 <armax> give or take
22:21:49 <armax> but I am no longer the start of the room so that doesn’t matter :(
22:21:52 <armax> *star
22:21:59 <kevinbenton> armax: ok
22:22:12 <kevinbenton> armax: but you will need to be there for stadium discussions
22:22:12 <armax> I won’t be landing in ATL until Monday morning
22:22:19 <armax> so I might skip some of the early morning session
22:22:22 <kevinbenton> armax: to explain what the stadium is, etc. :)
22:22:25 <armax> kevinbenton: totally
22:22:39 <armax> I thought we were going to undo everything I did, no?
22:22:48 <armax> new PTL, new regime
22:23:00 <kevinbenton> kind of hard to undo nothing :)
22:23:30 <kevinbenton> monday and tuesday are cross-projectish
22:23:58 <kevinbenton> should we try to sit down with nova folks then?
22:24:11 <armax> totally
22:24:13 <clarkb> I am told rooms are "hollow square" or "board room" with extra chairs for perimeter if needed. All rooms have tables
22:24:40 <armax> clarkb: thanks, I wonder about capacity
22:24:45 <armax> clarkb: do you happen to know?
22:25:00 <kevinbenton> we can have a repeat of vancouver :)
22:25:13 <kevinbenton> pack 60 people into a room for 20
22:25:39 * clarkb asks
22:25:54 <clarkb> the shared reservable projector rooms are fishbowl style and are the exception apparently
22:26:23 <kevinbenton> clarkb: who has those ones?
22:26:42 <clarkb> kevinbenton: they are shared and reservable in 30 minute chunks by any group. ttx sent email today wiht link to ethercalc page to do that
22:26:51 <kevinbenton> clarkb: ah, cool
22:27:26 <kevinbenton> so maybe we can make use of a couple of those for things like stadium discussion
22:27:29 <clarkb> I am told neutron room is set for 52 with 10 extra chairs. "huge salon"
22:27:37 <kevinbenton> oh
22:27:43 <kevinbenton> that sounds like it would probably be big enough
22:27:45 <ihrachys> which may mean hard to split?
22:28:08 <armax> https://ethercalc.openstack.org/Pike-PTG-Discussion-Rooms
22:31:10 <kevinbenton> is there anything else PTG related
22:31:15 <kevinbenton> ?
22:31:37 <armax> none from me
22:31:55 <ihrachys> like topics covered? are we set on the list? anything missing? redundant?
22:32:13 <kevinbenton> i will go over the list early next week and check for any new entries from the other one
22:32:30 <kevinbenton> and we can finalize it next drivers meeting
22:32:37 <armax> probably worth sending another email reminder to give people one more chance to chime in one more time
22:32:44 <armax> same for the postmortem
22:32:46 <kevinbenton> i'm going to add some comments for things i want clarification on
22:32:55 <ihrachys> ok, sounds fine
22:32:55 <armax> https://review.openstack.org/#/c/425990/
22:33:58 <kevinbenton> ok, i'll send out an email for each after the meeting
22:34:41 <kevinbenton> Do we want to move onto some RFE reviews?
22:34:53 <kevinbenton> or just wait until after PTG?
22:35:10 <armax> I have not had the chance to scan the list
22:35:21 <armax> but there was something interesting that captured my attention yesterday
22:35:47 <armax> https://review.openstack.org/#/c/421961/
22:36:28 <armax> and bug 1658682
22:36:28 <openstack> bug 1658682 in neutron "port-security can't be disabled if security groups are not enabled" [Wishlist,Confirmed] https://launchpad.net/bugs/1658682
22:36:40 <armax> the former is about something nonsensical we had in our code for ages
22:36:52 <armax> the other is about a config knob that alters API behavior
22:36:59 <armax> both should be looked at, IMO
22:37:32 <armax> and tangential one is bug 1633280
22:37:32 <openstack> bug 1633280 in neutron "[RFE]need a way to disable anti-spoofing rules and yet keep security groups" [Wishlist,Confirmed] https://launchpad.net/bugs/1633280
22:38:07 <kevinbenton> one at a time! :)
22:38:13 <kevinbenton> https://review.openstack.org/#/c/421961/
22:38:16 <kevinbenton> so i just read that one
22:39:11 <kevinbenton> armax: when you say "lets fix it"
22:39:20 <kevinbenton> armax: do you mean change the API definition?
22:39:31 <kevinbenton> armax: or fix the plugins to support it?
22:39:34 <armax> I guess changing the API would be non-bw compat
22:39:45 <armax> but right now rejecting the request is the same thing
22:40:11 <armax> can’t recall if allow_put=False returns 400 or forbidden
22:40:32 <armax> kevinbenton: either, or
22:40:51 <kevinbenton> right, we might end up with a different error code
22:40:54 <armax> keeping the raise function, and furthermore have it in neutron-lib seems the wrong thing to do
22:41:45 <kevinbenton> maybe we should just fix the plugins...
22:41:57 <kevinbenton> for ML2 it's not that unreasonable i don't think
22:42:05 <kevinbenton> now that we have the segments plugin
22:42:11 <kevinbenton> it's effectively a segment delete and create
22:42:49 <armax> kevinbenton: actually it’s the same error code
22:42:50 <armax> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/api/v2/base.py#n721
22:42:54 <armax> different message though
22:43:02 <kevinbenton> yeah
22:43:16 <armax> I am ok either way
22:43:16 <kevinbenton> but I think we should move away from it
22:43:36 <kevinbenton> i agree it shouldn't be in neutron-lib
22:43:40 <armax> I am simply opposed to kick the can down the road
22:43:43 <kevinbenton> we shouldn't encourage skipping a feature
22:44:00 <ihrachys> agreed on neutron-lib change being incorrect either way; as for the solution, ideally we would make it work without api change, but realistically, we could as well squeeze that small change into the map; and leave it up for an RFE to allow updates, at which point we would flip allow_put back.
22:44:34 <kevinbenton> ihrachys: but why put that in the API def?
22:44:54 <kevinbenton> ihrachys: a plugin could work with it now
22:45:23 <armax> I think boden was simply moving code around to avoid dependency on neutron import
22:45:25 <ihrachys> if we think there can be a plugin that supports it, yeah, then it makes sense to just implement the damned thing
22:46:15 <kevinbenton> yeah, i would rather push that way
22:46:24 <kevinbenton> file a bug saying ML2 is broken because it raises :)
22:46:44 <armax> it’s not just ml2
22:46:46 <kevinbenton> bug 1658682
22:46:46 <openstack> bug 1658682 in neutron "port-security can't be disabled if security groups are not enabled" [Wishlist,Confirmed] https://launchpad.net/bugs/1658682
22:46:59 <kevinbenton> armax: i know, but if ml2 goes that way, we can encourage others to follow
22:48:59 <kevinbenton> armax: so it sounds like there is some validation that needs to be fixed here
22:49:23 <kevinbenton> at a minimum
22:49:53 <armax> right, but if we had no way to disable security groups from a config point of view
22:49:59 <armax> the bug would go away, wouldn’t it?
22:50:37 <kevinbenton> yeah, but that kills a use case from what i can see
22:50:44 <kevinbenton> they don't want filtering by default
22:50:51 <kevinbenton> inbound to instances
22:51:04 <armax> by having port_security = False and no security groups on the port that should do it , no?
22:51:08 <kevinbenton> maybe we need to take the configurable default security groups horse back out for a beating
22:51:24 <kevinbenton> no, they want the protection from port security by default
22:51:28 <kevinbenton> with no security groups
22:51:50 <armax> then have —no-security-groups and port-security=True
22:51:51 <kevinbenton> and then to disable port security "on a few ports"
22:52:12 <kevinbenton> what is --no-security-groups?
22:52:31 <kevinbenton> oh
22:52:34 <kevinbenton> on every port create
22:52:41 <armax> that’s the CLI option
22:52:45 <kevinbenton> but that requires user behavior change
22:52:54 <armax> to clear secgroups
22:53:12 <armax> as it is that’s not great,
22:53:25 <armax> we probably need to turn the config option into API driver behavior? dunno
22:53:46 <kevinbenton> basically it's operator configurable security groups
22:53:50 <kevinbenton> default
22:53:58 <armax> but personally I don’t like that
22:53:59 <kevinbenton> with one option, "allow all"
22:54:21 <kevinbenton> anyway, i think this validation should go away anyway "Cannot disable port security or ip address until security group is removed"
22:55:10 <ihrachys> let the horse (configurable default groups) die in peace, it's not going to run, it's a breach in cloud compatibility.
22:56:34 <kevinbenton> yeah, i think we will just need to leave this config option and fix port security validation
22:56:41 <kevinbenton> to work in this case
22:57:15 <trevormc> hi all, sorry to interrupt, I added an rfe this week bug 1662650 I'm just making sure I'm following the rfe process. Next step is "neutron-drivers team acknowledges the bug" ?
22:57:15 <openstack> bug 1662650 in neutron "[RFE] Accelerating SR-IOV with DPDK" [Undecided,New] https://launchpad.net/bugs/1662650
22:57:18 <ihrachys> indeed that should be easier to sell than option deprecation
22:57:19 <armax> so you don’t want to kill the config option or not?
22:57:40 <kevinbenton> armax: i'm not sure we can
22:57:45 <armax> I am not sure I understood what you want to do
22:58:22 <kevinbenton> trevormc: yep, you did. we're missing a chunk of the drivers team and the PTG is around the corner so we aren't talking about new RFE's this week
22:58:30 <kevinbenton> armax: leave the config option alone
22:58:33 <trevormc> ok thx
22:58:54 <kevinbenton> armax: fix the validation logic to allow port security to be shut off
22:59:13 <armax> I disagree, but ok
22:59:41 <ihrachys> 1 min
22:59:50 <kevinbenton> well they don't want security groups API in their cloud
23:00:01 <kevinbenton> we could deprecate i suppose
23:00:04 <kevinbenton> but that will be a battle
23:00:05 <kevinbenton> okay
23:00:15 <ihrachys> kevinbenton: do we allow other apis to be selected for ml2 like that?
23:00:15 <kevinbenton> talk more outside
23:00:25 <kevinbenton> ihrachys: unfortunately. it's upsetting
23:00:26 <ihrachys> anyway, it's not necessarily discussion for the bug
23:00:29 <armax> that’s not why the knob was introduced though
23:00:30 <kevinbenton> #endmeeting