22:02:38 <kevinbenton> #startmeeting neutron_drivers
22:02:39 <openstack> Meeting started Thu Apr  6 22:02:38 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:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:02:42 <openstack> The meeting name has been set to 'neutron_drivers'
22:02:46 <mlavalle> o/
22:02:51 <kevinbenton> amotoki, ihrachys, mlavalle: ping
22:02:55 <kevinbenton> hello!
22:02:59 <amotoki> hi
22:03:06 <kevinbenton> armax can't join us, he's giving a talk at ONS right now about Neutron
22:03:24 <ihrachys> o/
22:03:38 <amotoki> nice to hear that :)
22:03:47 <mlavalle> yeah, that's good
22:03:50 <bzhao_> o/
22:04:26 <kevinbenton> so the results of the doodle of where to move the drivers meeting are in
22:04:35 <mlavalle> good
22:04:40 <kevinbenton> and the result is that there is no good time we can agree on
22:05:08 <ihrachys> yay! /s
22:05:23 <mlavalle> kevinbenton: I'll make it simple. You tell the time and I'll accomodate to whatever you and the others decide
22:05:35 <kevinbenton> it basically comes down to Armando can't do early morning, and that's the only convenient intersection for Ihar and Akihiro
22:06:10 <ihrachys> ok, I guess we will stick to what we have
22:06:31 <kevinbenton> yeah, i think that's the only option for now
22:06:39 <ihrachys> I suspect a similar case is for the neutron meeting on Mondays? :-x
22:06:46 <amotoki> I didn't mark 17UTC timeslot but I can get up late but even though we still have no intersection with armando timeslots :(
22:07:14 <kevinbenton> yeah
22:07:45 <kevinbenton> Monday might be a little more flexible
22:07:53 <ihrachys> ok I guess I will trim my Fridays to the point where I won't work :P
22:07:55 <mlavalle> Monday works for me
22:07:55 <kevinbenton> we can chat about that in next monday team meeting
22:08:02 <ihrachys> +
22:08:13 * haleyb reads-up on cloning experiments
22:08:24 <kevinbenton> mlavalle: ihrachys was referring to the Neutron team meeting time change we attempted and failed :)
22:08:32 <mlavalle> ah, ok
22:08:37 <kevinbenton> #info drivers team meeting staying at the same time for now
22:08:49 <kevinbenton> #topic RFE's
22:08:52 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:09:35 <ihrachys> I admit I didn't have time for anything drivers related this week
22:09:42 <kevinbenton> that's okay
22:09:48 <kevinbenton> let's do easy ones :)
22:10:08 <ihrachys> like SNAT?? :)
22:10:17 <mlavalle> yeah that one
22:10:19 <kevinbenton> now that the dissenting opinion is gone, what do we think about? https://bugs.launchpad.net/neutron/+bug/1671634 ;)
22:10:20 <openstack> Launchpad bug 1671634 in neutron "[RFE] Allow to set MTU for networks" [Wishlist,Triaged] - Assigned to Ihar Hrachyshka (ihar-hrachyshka)
22:10:30 <kevinbenton> we'll wait for armando to reply on that
22:10:46 <kevinbenton> let's skip SNAT as well because i need to see what Igor said on fast exit patch
22:10:48 <ihrachys> I am puzzled on why it's controversial, but sure, we need armax
22:11:10 <kevinbenton> i think there is some confusion there because fast exit was different last time i looked
22:11:46 <amotoki> are we discussing MTU or local SNAT?
22:12:02 <mlavalle> I think neither
22:12:08 <manjeets> lol
22:12:29 * manjeets thought its MTU
22:12:30 <ihrachys> yeah we wait for kevinbenton to post the next link
22:12:37 <ihrachys> mtu will need armax
22:12:41 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1672852
22:12:42 <openstack> Launchpad bug 1672852 in neutron "[RFE] Make controllers with different list of supported API extensions to behave identically" [Wishlist,Triaged] - Assigned to Ihar Hrachyshka (ihar-hrachyshka)
22:12:42 <amotoki> agree
22:13:06 <ihrachys> that's on me. I posted a spec here: https://review.openstack.org/451993
22:13:23 <ihrachys> I know that it may not go further but thought a detailed write-up will benefit discussion
22:13:40 <kevinbenton> ack
22:13:55 <kevinbenton> i do want to seriously consider the sticky sessions approach
22:13:59 <ihrachys> I am still not sure it's a great idea, because it targets solving issues that are not immediately present in current code but suggests a path to evolve new features in the future
22:14:27 <ihrachys> right, that's one solution that solves half of the problem
22:14:27 <kevinbenton> we need to think through the cases where that would break and clearly illustrate them before undertaking the big pile of work this will take
22:14:39 <ihrachys> I actually agree
22:14:48 <kevinbenton> ihrachys: what's the other half of the problem?
22:14:48 <ihrachys> there are also some limitations in the proposal
22:14:58 <ihrachys> due to the fact that our api is liberal
22:15:24 <ihrachys> the other half is, what if a new resource representation is put into db and then should be parsed by unaware old server
22:15:56 <kevinbenton> ihrachys: i'm not sure i understand, isn't that what the point of expand-only scripts is?
22:16:00 <ihrachys> the proposal targets blocking that case on api level, so that you can't get a new expanded resource in db before all servers are upgraded
22:16:13 <amotoki> we are now using extensions to indicate a new feature and minor versioning. for features the idea would work, but for minor versioning (aka shim extension) I am not sure it works.
22:16:40 <ihrachys> kevinbenton, the point of expand scripts is that you can execute them while neutron-server is running; not that plugin code will necessarily behave correctly.
22:16:58 <kevinbenton> ihrachys: well if it breaks old server i'd say it's not really an expand script
22:17:00 <ihrachys> amotoki, not sure which versioning we talk about
22:17:28 <kevinbenton> let's take time to review the spec and comment there
22:17:30 <amotoki> ihrachys: what I mean is we have shim extension (or light extension) for minor behavior changes.
22:17:45 <ihrachys> kevinbenton, well it's one thing that a column added (but not filled) doesn't break a server; it's another thing that server can make sense of the column filled in with data
22:17:57 <ihrachys> + for more time to bake/think/review spec...
22:18:13 <amotoki> for such changes, I am not sure we can ensure a plugin works correctly if we disable some a new extension
22:18:20 <kevinbenton> ihrachys: well the old server would ignore it
22:18:34 <ihrachys> amotoki, we should not have cases where we modify behaviour of existing attributes
22:19:00 <kevinbenton> ok
22:19:11 <ihrachys> kevinbenton, server may be scheduled to act on the resource that is represented with new data in db; it may choke on it. (that's hypothetical)
22:19:35 <amotoki> ihrachys: agree. if we find exception we need to fix it
22:19:54 <ihrachys> ok, I guess we agree to follow up in lp and gerrit
22:20:12 <mlavalle> so, comment on the spec
22:20:20 <amotoki> +1 for spec
22:20:24 <kevinbenton> ihrachys: right, it sounds like that violates the point of hte expand script. maybe we aren't as strict as i thought. would be good to have some sample scenarios you envision in the spec that would break
22:20:36 <kevinbenton> ok, next
22:20:43 <amotoki> as high level, there is no reason to block this
22:21:12 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1674349
22:21:14 <openstack> Launchpad bug 1674349 in neutron "[RFE] Introduce a new rule with service user role in Neutron policy" [Wishlist,Triaged] - Assigned to Akihiro Motoki (amotoki)
22:21:15 <ihrachys> amotoki, complexity
22:21:51 <ihrachys> re the service user bug, we actually started work I believe
22:22:02 <amotoki> I think this one is super simple. we already consume more attributes from keystone.
22:22:22 <amotoki> yes we started it. I think this can be handles as a normal bug
22:22:32 <ihrachys> it seems like a no brainer
22:22:34 <kevinbenton> yes
22:22:36 <kevinbenton> approve
22:22:42 <mlavalle> yes, approve
22:22:50 <kevinbenton> this will be nice
22:23:00 <ihrachys> yeah we talk about it for a while
22:23:05 <kevinbenton> having nova doing network things for the user with admin privileges has always made me nervous
22:23:33 <amotoki> yes. service token is a nice feature
22:23:33 <kevinbenton> https://en.wikipedia.org/wiki/Confused_deputy_problem
22:23:35 <ihrachys> afaik it's also related to timeout issues they had for long operations
22:23:59 <kevinbenton> ihrachys: can you switch to approved state?
22:24:04 <ihrachys> sure
22:24:33 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1667329
22:24:34 <openstack> Launchpad bug 1667329 in neutron "[RFE] Floating IP Subnets on Routed Provider Networks" [Undecided,Triaged]
22:25:55 <kevinbenton> mlavalle: how familiar are you with the plans for this?
22:26:03 <mlavalle> somehow familiar
22:26:13 <kevinbenton> if i understand the proposal correctly, it will be a very limited change on neutron side
22:26:33 <mlavalle> it is the completion of the of the routed networks spec
22:26:50 <mlavalle> we discussed it this morning during the L3 team meeting
22:27:18 <mlavalle> On the Neutron side is  not that big
22:28:11 <amotoki> It also needs a change on dynamic-routing-side. this looks a main part.
22:28:23 <mlavalle> that is correct
22:28:52 <kevinbenton> oka
22:28:59 <kevinbenton> so is john going to work on this then?
22:29:14 <mlavalle> yes and I plan to pitch in
22:29:38 <mlavalle> He actually proposed this morning to start working on is as WIP while the RFE is approved
22:30:01 <kevinbenton> sounds good
22:30:13 <kevinbenton> i'm okay approving this one
22:30:23 <kevinbenton> i don't see it conflicting with other ongoing work in neutron
22:30:37 <mlavalle> yeah, me neither
22:30:49 <kevinbenton> ihrachys, amotoki: any issues approving this one?
22:30:57 <amotoki> I am fine with approving it
22:31:17 <ihrachys> I am ok, though I don't grasp l3 things, so you can also ignore me :)
22:31:33 <amotoki> the next step is a spec?
22:31:43 <mlavalle> we don't want to ignore you, ihrachys :-)
22:31:46 <ihrachys> I think also a blueprint (though I am not sure why we do it)
22:32:13 <kevinbenton> ihrachys: blueprint makes visibility in launchpad easier
22:32:29 <ihrachys> kevinbenton, well if you target to pike-1 it will show in the target...
22:32:37 <ihrachys> so not sure how it helps
22:32:49 <ihrachys> ofc except requiring to set approver and author...
22:33:09 <kevinbenton> ihrachys: as a bug though
22:33:22 <kevinbenton> ihrachys: separating features from bugs is somewhat useful
22:33:34 <ihrachys> well if only that, sure
22:33:44 <kevinbenton> ihrachys: yeah, i'm not sure if there is another advantage
22:33:59 <ihrachys> so tl;dr there is some legwork to set all things correctly, the RFE process in devref has details
22:34:20 <ihrachys> someone should just commit now to do the work
22:35:01 <kevinbenton> ok
22:35:12 <kevinbenton> there is one more i would like to discuss that has a thorny backward compatibility issue
22:35:16 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1669630
22:35:17 <openstack> Launchpad bug 1669630 in neutron "Network RBAC acceptance workflow" [Wishlist,Triaged]
22:36:01 <ihrachys> oh I remember that one. we can always introduce new types of rbacs that will need approval ;)
22:36:32 <ihrachys> I don't think controlling behaviour with config option is a great idea
22:36:32 <kevinbenton> ihrachys: oh, i didn't think about that
22:36:40 <kevinbenton> ihrachys: a new type might not be bad
22:36:48 <ihrachys> since it is a step from cross-cloud compatibility
22:37:01 <kevinbenton> ihrachys: then operators could block access_as_shared with policy.json
22:37:41 <ihrachys> yeah, like approve:access_as_shared or smth
22:37:48 <ihrachys> maybe even make it a pattern for all rules
22:38:17 <kevinbenton> yeah, we want to make sure it's a general solution
22:38:29 <ihrachys> or make it a new attribute on existing rbac rule that suggests if approval is needed.
22:39:09 <kevinbenton> i suppose policy.json is sort of like having it config driven though
22:39:44 <ihrachys> yeah. I don't think we should ask users to make it. just add approval as an auxiliary parameter of rbac
22:39:59 <ihrachys> then we can make our CLI clients use it by default
22:40:04 <ihrachys> or smth
22:40:33 <kevinbenton> well then we still have the issue where we are technically breaking the API by changing behavior
22:40:54 <kevinbenton> since a user using the API will now require the other user to accept the shared thing before using it
22:41:19 <amotoki> IIRC I think some other project (glance?) has similar mechansim. In the impl,  even though they do not approve a network share request, they can use it.
22:42:01 <ihrachys> kevinbenton, but default behaviour will be as it is now?
22:42:14 <ihrachys> not sure I see where compat issue here is
22:42:40 <kevinbenton> ihrachys: so are you suggesting that we continue to allow users to share without requiring approval?
22:42:49 <ihrachys> the original compat issue was that we will change behaviour for rbacs that are created by scripts written pre-fix
22:43:02 <ihrachys> kevinbenton, ah well, yeah, I forgot about the use case!
22:43:03 <ihrachys> :)
22:43:04 <amotoki> I understand the challenging point is what should be the default. It is a big change for users who some resources are exposed to.
22:43:27 <kevinbenton> amotoki: right
22:43:37 <kevinbenton> we can always migrate everything now to the already approved state
22:43:54 <kevinbenton> the issue is API behavior change going forward of not being approved by default
22:44:02 <amotoki> yeah
22:44:23 <mlavalle> yeah, we change the bahavior
22:44:32 <ihrachys> ok, I guess a new resource would be the easiest, and we would keep both for some transition time
22:44:51 <ihrachys> then just drop it from our code (but not api-ref)
22:45:04 <ihrachys> it == old impl
22:45:12 <kevinbenton> ihrachys: so basically a whole new API endpoint?
22:45:27 <kevinbenton> ihrachys: and they ultimately do the same thing, but one auto-approves and one doesn't?
22:45:31 <kevinbenton> that could work
22:45:37 <amotoki> another idea is to allow a user to deny resource sharing.... a resource shared is visible to users but the user can deny the share.
22:46:29 <amotoki> it is a bit different from the original RFE though..
22:46:36 <kevinbenton> but that requires user to opt-in to a safety feature
22:46:43 <kevinbenton> which i would like to avoid if we can
22:47:40 <kevinbenton> and if operators automate that as part of tenant onboarding, then we basically have the same problem of a user not knowing if they need to accept or not
22:48:16 <amotoki> it is just a brainstorming. of course I think opt-in model looks natural for many users in this case
22:49:07 <kevinbenton> ok, provide thoughs on the RFE
22:49:14 <kevinbenton> and we can discuss again next week
22:49:37 <kevinbenton> i'm actually leaning towards the new API option as of now
22:50:08 <mlavalle> I am also leaning in that direction
22:51:12 <kevinbenton> ok
22:51:18 <kevinbenton> that's the last of the RFE's
22:51:18 <amotoki> that sounds a good possible direction. I am wondering how glance handles it and need to check it
22:51:35 <trevormc> hi all, sorry to interrupt. I added an rfe the week of the 02/09 drivers meeting bug 1662650. I believe my bug has been acknowledged but it's status has not been moved to confirmed yet, so I think it fell through the cracks some how?
22:51:36 <openstack> bug 1662650 in neutron "[RFE] Advance configuration of SR-IOV ports- api extension" [Wishlist,New] https://launchpad.net/bugs/1662650 - Assigned to Trevor McCasland (twm2016)
22:51:41 <mlavalle> amotoki: yeah, maybe part of the homework is to find that out
22:51:42 <ihrachys> I posted a comment with new api suggested
22:52:10 <kevinbenton> trevormc: ah, hasn't been triaged yet
22:52:15 <kevinbenton> we can look now
22:52:48 <trevormc> thank you! It's rough but I do have a vf_policy object in review to give an idea.
22:53:33 <kevinbenton> trevormc: many of these sound like they should be derived from existing APIs
22:53:57 <kevinbenton> like allowing/dropping broadcast
22:54:12 <kevinbenton> or antispoofing
22:54:16 <ihrachys> kevinbenton, you mean secgroups?
22:54:26 <kevinbenton> i think those should be higher level properties of neutron network or port security
22:54:28 <kevinbenton> ihrachys: right
22:54:36 <trevormc> I believe port_security already covers the antispoofing
22:54:52 <ihrachys> right. sriov may have its implementation of firewall_driver instead of using noop as they do now
22:54:52 <kevinbenton> i don't think we want to expose these directly as properties if they sort of overlap with existing abstractions
22:55:13 <kevinbenton> VLAN_STRIP sounds like vlan_transparency
22:56:12 <amotoki> INSERT_TAG sounds a normal operation as OVS does.
22:56:39 <trevormc> yeah but I thought at the PTG we discussed that vlan transparency only applied to tags in one direction and not both
22:57:23 <kevinbenton> trevormc: vlan transparency just allows tagged traffic to pass in and out of a port without being modified
22:57:45 <kevinbenton> trevormc: i think we need to discuss these basically one-by-one in the RFE
22:58:05 <kevinbenton> trevormc: i'll leave comments and we can talk about it next drivers meeting
22:58:08 <mlavalle> yeah, matching with current Neutron capabilities
22:58:20 <ihrachys> I am not sure what INSERT_TAG is, you may want to elaborate there on it
22:58:21 <amotoki> I totally agree with kevin
22:58:46 <trevormc> yeah I think that will be better, thanks. I'll have to talk to the guys who are driving this through me :)
22:58:54 <kevinbenton> ok
22:58:55 <ihrachys> +
22:58:57 <kevinbenton> thanks everyone
22:59:07 <kevinbenton> same time next week! :)
22:59:08 <mlavalle> see you next week!
22:59:12 <kevinbenton> #endmeeting