22:01:49 <kevinbenton> #startmeeting neutron_drivers
22:01:50 <openstack> Meeting started Thu Jun 22 22:01:49 2017 UTC and is due to finish in 60 minutes.  The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:53 <openstack> The meeting name has been set to 'neutron_drivers'
22:02:15 <kevinbenton> boden is only with us for the first half of the meeting and wanted to share some items
22:02:18 <kevinbenton> boden: take the floor!
22:02:23 <boden> sure
22:02:38 <mlavalle> welcome boden
22:02:56 <boden> there’s a set of 2 patches out for review that add an api_status attribute to the /extensions API
22:03:07 <boden> #link https://review.openstack.org/#/c/475577
22:03:16 <boden> #link https://review.openstack.org/#/c/475792/
22:03:49 <boden> we were hoping folks could find a few min to weigh-in on them in the near future
22:04:24 <kevinbenton> the quick context is that it would be nice to have an easily visible way to tell which APIs are still being developed and might be unstable
22:04:51 <mlavalle> I already took a look at the patchsets and it makes sense to me
22:04:57 <hichihara> I agree the feature.
22:05:26 <hichihara> But there is a Akihiro's comment on patch set.
22:05:54 <hichihara> His comment is the feature may need shim extension.
22:05:56 <kevinbenton> yes, we might need an extension to discover the extension to extensions :)
22:06:08 <hichihara> :)
22:06:35 <boden> can we just move the discussion to the patches?
22:06:44 <mlavalle> but I think that implies akihiro is on board with the feature
22:06:51 <kevinbenton> yep, unless armax or mlavalle have any immediate concerns
22:07:04 <mlavalle> I am ok with this feature
22:07:13 <armax> kevinbenton: unfortunately I dropped during the first few mins of the meeting
22:07:24 <armax> the eavedrops have not loaded yet so I lost context
22:07:36 <armax> I’ll have to catch up
22:07:44 <armax> and provide feedback elsewhere
22:07:52 <boden> armax: https://review.openstack.org/#/c/475577/
22:08:27 <armax> boden: ack
22:08:38 <boden> I will address the comments
22:08:46 <kevinbenton> ok
22:09:17 <boden> ready to move onto the last item?
22:09:21 <kevinbenton> yep
22:09:47 <boden> for the neutron-lib work we need a way to decouple database imports from neutron
22:09:57 <boden> a few weeks ago I proposed a spec https://review.openstack.org/#/c/473531/
22:10:08 <boden> today I added some PoC code and updated spec
22:10:35 <boden> we won’t be able to wrap up the neutron-lib work for networking-ovn in pike without some solution here
22:11:17 <kevinbenton> boden: ok. is that the final blocker for networking-ovn?
22:12:04 <armax> boden: what % are we at with OVN?
22:12:09 <boden> kevinbenton: well, with the approach proposed really anything could be “pluggable” if we agree to it.. so the answer depends on the final solution
22:12:28 <boden> armax: I haven’t been tracking that closely
22:12:48 <armax> boden: OK
22:13:03 <boden> armax: http://codesearch.openstack.org/?q=from%20neutron
22:13:08 <boden> we still have some work left
22:13:12 <boden> including the ML2Plugin
22:13:56 <kevinbenton> ok. i'll get this spec reviewed
22:14:06 <boden> maybe this is a better search for ovn: http://codesearch.openstack.org/?q=from%20neutron%5B%5C.%7C%20import%5D&i=nope&files=&repos=networking-ovn
22:14:45 <mlavalle> I will also find time soon to review the spec
22:14:46 <boden> that’s all from me, unless there are questions/comments
22:14:51 <armax> boden: tehre’s a script that tracks the %
22:14:57 <armax> in the lib repo
22:15:16 <boden> armax: ack
22:15:27 <armax> don’t have an env handy right now
22:15:39 <armax> to come up with the number though
22:15:44 <armax> hence my question :)
22:16:39 <kevinbenton> boden: ok. was that all?
22:16:39 <boden> armax: my guess is we are 60’some % complete
22:16:44 <boden> dart board says so
22:16:52 <boden> kevinbenton yup thanks
22:16:58 <kevinbenton> boden: thanks
22:17:25 <armax> boden: that’s good progress
22:17:31 <kevinbenton> i'd like to discuss an RFE we were waiting on feedback from the contributor for
22:17:36 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1649417
22:17:37 <openstack> Launchpad bug 1649417 in neutron "RFE: Security group rule using address set" [Wishlist,Triaged]
22:17:50 <kevinbenton> so the reporter has volunteered to do the work
22:17:52 <mlavalle> it seems they don't have time
22:18:27 <kevinbenton> Han Zhou said they will contribute
22:18:47 <mlavalle> kevinbenton: you are right
22:18:50 <mlavalle> I misread
22:19:18 <mlavalle> I would like Han Zhou assign himslef or anyone else soon, though
22:19:47 <kevinbenton> i think the question here is going to be how it integrates with the existing SG API
22:20:03 <kevinbenton> shall we approve it and wait for a spec?
22:20:35 <kevinbenton> or does anyone think this shouldn't be added as a feature?
22:21:44 <mlavalle> I would be interested in seeing a spec
22:22:37 <kevinbenton> armax: any objections to allowing it to proceed to spec?
22:22:58 <armax> kevinbenton: there’s no user facing impact, is there?
22:23:06 <kevinbenton> armax: there is
22:23:13 <kevinbenton> armax: it's a new API to define sets of addresses
22:23:23 <kevinbenton> which can then be referenced somehow in the SG API
22:23:31 <mlavalle> it's kind of the point of the rfe
22:23:52 * armax is slow at catching up
22:24:02 <armax> sure, spec sounds good
22:24:40 <kevinbenton> ok
22:25:41 <kevinbenton> next up
22:25:43 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1653932
22:25:44 <openstack> Launchpad bug 1653932 in neutron "[rfe] network router:external field not exported" [Wishlist,Triaged] - Assigned to Kevin Benton (kevinbenton)
22:25:56 <kevinbenton> so i did some digging on this
22:26:17 <kevinbenton> in order for policy.json to have an entry referencing a field in a parent object
22:26:41 <kevinbenton> we do need a change to the policy engine to allow lookups for 'field' rules like we allow for 'tenant_id' rules
22:28:03 <kevinbenton> my assessment is that the policy engine changes are reasonable to support these types of rules
22:29:00 <kevinbenton> so i would at least like to approve this one to enable operators to write a policy rule that allows users to see external subnets
22:29:17 <armax> kevinbenton: how different would the code look like compared to https://review.openstack.org/#/c/476094?
22:29:43 <kevinbenton> armax: that is pretty much it
22:29:54 <armax> can the patch lead to potential races where now subnets all of a sudden start showing up?
22:29:57 <armax> in order words
22:30:05 <armax> does it make sense to change the default policy.json?
22:30:10 <armax> or leave it as is
22:30:11 <kevinbenton> right
22:30:17 <kevinbenton> so there are two parts to the RFE
22:30:22 <kevinbenton> one is allowing the rule
22:30:29 <kevinbenton> the other is us making the rule the default
22:30:33 <kevinbenton> I'm not sure about the latter
22:30:36 <armax> agreed
22:30:58 <kevinbenton> I'm sure there are tempest tests that will list all subnets visible to a tenant and then explode when this merges
22:31:00 <armax> would the patch be able to handle other attributes like router:external
22:31:07 <armax> or is it a special case?
22:31:16 <kevinbenton> armax: nope, not a special case
22:31:21 <armax> OK
22:31:30 <armax> then we should err on the side of caution
22:31:30 <kevinbenton> so it should apply to any field match rules needing to reference another object
22:31:46 <armax> enable the logic but keep the json file as is, release note and document the cahnge and move on
22:31:53 <armax> that’d be my suggestion
22:32:15 <kevinbenton> ok, mlavalle does that sound reasonable
22:32:16 <kevinbenton> ?
22:32:19 <mlavalle> yeap
22:32:33 <mlavalle> the poc was a good idea
22:34:04 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1667877
22:34:05 <openstack> Launchpad bug 1667877 in neutron "[RFE] Allow DVR for E/W while leaving N/S centralized" [Wishlist,Triaged]
22:34:08 <kevinbenton> so i don't want to beat a dead horse
22:34:28 <kevinbenton> i just wanted to point out that I've updated that RFE to separate the proposed implementation from the requirement
22:34:48 <kevinbenton> armax: if you could take a look at that and comment on if you agree with the use case or not that would be good
22:35:32 <armax> kevinbenton: I have been meaning to reach out to you
22:35:39 <armax> as I also have been giving this some thought
22:35:59 <kevinbenton> ok, let's discuss outside of our precious drivers time :)
22:36:02 <armax> I’ll have a look and reach out for details
22:36:12 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1669630
22:36:13 <openstack> Launchpad bug 1669630 in neutron "Network RBAC acceptance workflow" [Wishlist,Triaged]
22:36:13 <armax> so long as people are ok with us having a secret meeting
22:36:21 <kevinbenton> armax: we can do it in openstack-neutron
22:36:32 <armax> no, secret!!
22:36:34 <armax> :)
22:36:34 <mlavalle> yeah, it doesn't have to be secret
22:37:09 <kevinbenton> so i think we have discovered a way forward with this RFE
22:37:14 <armax> kevinbenton: nice
22:37:38 <armax> I remember when we talked during one of our (secret) meetings we were unable to go past the sticking non-bw compat point
22:37:41 <kevinbenton> existing API behaves as it currently does
22:37:53 <kevinbenton> and we add a new endpoint that requires acceptance
22:38:05 <kevinbenton> then operators can choose to banish the legacy API via policy.json
22:38:28 <armax> you’ve just implemented poor man’s microversioning! I like it
22:38:35 <mlavalle> LOL
22:38:38 <kevinbenton> it's not super great, but it seems to be the best we can do since the ask is fundamentally to break existing behavior :)
22:38:54 <armax> let’s give this some thought
22:39:01 <armax> this feels like a slippery slope
22:39:17 <armax> kevinbenton: can I say that?
22:39:19 <kevinbenton> ok, i'm also going to ask the requestor if he has resources to work on it
22:39:38 <kevinbenton> armax: well you already did :)
22:39:57 <armax> I can take it back
22:41:07 <kevinbenton> ok, let's come back to this one
22:41:47 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1671448
22:41:48 <openstack> Launchpad bug 1671448 in neutron "[RFE] Neutron quota api should be configurable via policy.json" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee)
22:42:06 <kevinbenton> this is just making the policy engine enforce quota requests
22:42:32 <mlavalle> we now Ihar supports this one. He says so in the comments
22:42:32 <kevinbenton> reedip has volunteered and it should be pretty isolated work as Ihar has pointed out
22:42:47 <kevinbenton> so I think this one is good to go even without a spec
22:43:11 <kevinbenton> it's just making quota API consistent with the other APIs
22:43:20 <kevinbenton> WRT policy
22:44:09 <kevinbenton> any naysayers?
22:44:18 <mlavalle> I am ok with it as well
22:45:15 <kevinbenton> armax: ?
22:45:47 <armax> OK
22:46:33 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1672920
22:46:34 <openstack> Launchpad bug 1672920 in neutron "[RFE] Flavor support for VPNaaS" [Wishlist,Triaged] - Assigned to Hunt Xu (huntxu)
22:46:45 <kevinbenton> I think this is good to go
22:46:51 <kevinbenton> has support from vpnaas folks
22:48:41 <mlavalle> meaning yamamoto?
22:48:50 <kevinbenton> yeah
22:49:47 <kevinbenton> we can approve and let vpnaas core reviewers decide how to prioritize it
22:49:48 <mlavalle> I'm of with it
22:49:57 <mlavalle> ok^^^^
22:50:34 <kevinbenton> armax: in your comment it's not clear if you felt it should be blocked until other items are addressed
22:50:49 <armax> kevinbenton: you’d know my answer
22:51:16 <armax> if folks feel like working on feature development and prioritize over other stadium related efforts
22:51:50 <armax> that would be fine by me so long as vpnaas is still not qualifying as meeting stadium quality criteria
22:52:20 <armax> I mean, so long as we don expect to relax quality criteria and yet give a pass
22:52:38 <kevinbenton> sounds like approval to me :)
22:52:47 <armax> we shouldn’t even care
22:52:52 <armax> it’s not our problem at the moemnt
22:52:57 <kevinbenton> i will note that they should make sure it doesn't interfere with their stadium goal
22:53:06 <armax> that’s the beauty of it
22:53:21 <armax> empower people to make their own decisions
22:53:27 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1583694
22:53:28 <openstack> Launchpad bug 1583694 in neutron "[RFE] DVR support for Allowed_address_pair port that are bound to multiple ACTIVE VM ports" [Wishlist,In progress] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
22:53:32 <armax> I’d advice to focus energy and effort over other priority
22:54:29 <kevinbenton> i didn't realize this was an RFE
22:54:34 <kevinbenton> it's a bug fix
22:54:51 <armax> well it was an RFE
22:54:51 <kevinbenton> armax: do you have any issues with that request?
22:55:12 <armax> because we wanted to fix it in a way that impacted the API
22:55:23 <kevinbenton> the fix doesn't impact the API
22:55:26 <armax> last time I checked I had reserverations with the proposed implementations
22:55:41 <armax> if we could get a status update, or if you have one, I’d be happy to hear it
22:56:02 <armax> then, it’s still the problematic fix which I fear is gonna cause us grief
22:56:15 <kevinbenton> so the logic goes like this
22:56:21 <kevinbenton> (based on reading Swami's patches)
22:56:38 <kevinbenton> if a floating IP is associated with a bound port
22:56:42 <armax> frankly at this point I am frustrated that I am unable to influence direction or express why my concern is founded
22:56:43 <kevinbenton> everything works as it currently does
22:56:44 <armax> I give in
22:57:08 <kevinbenton> if the port is unbound, it's just hosted on the DVR_SNAT agent
22:57:12 <armax> without API changes, to make this use case move away from allowed address pairs as a hack
22:57:14 <kevinbenton> no config options
22:57:25 <armax> we’ll have a bug factory we’re gonna be dealing with
22:58:27 <armax> if I am the only one I see this danger, then I might be the only one who’s wrong
22:58:34 <armax> so let’s move on
22:58:47 <kevinbenton> armax: what is your issue with what i just described?
22:59:04 <mlavalle> yeah, I am interested in listening
22:59:21 <armax> it’s always the same
22:59:38 <armax> I have provided it time and time again
23:00:10 <armax> even in the bug report
23:00:14 <armax> time check
23:00:36 <kevinbenton> helpful :/
23:00:39 <kevinbenton> #endmeeting