22:01:27 <kevinbenton> #startmeeting neutron_drivers
22:01:28 <openstack> Meeting started Thu Jul 27 22:01: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:01:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:31 <openstack> The meeting name has been set to 'neutron_drivers'
22:01:31 <armax> ihrachys: you broke your chair?
22:02:06 <kevinbenton> this week is feature freeze
22:02:06 <ihrachys> armax, no, just falling asleep
22:02:23 <kevinbenton> starting next week any feature related things that need to merge will have to get an FFE
22:02:33 <armax> oh
22:02:41 <armax> boooo
22:02:59 <kevinbenton> excluding simple things like docs
22:03:04 <kevinbenton> or additional API tests are always welcome
22:03:06 <kevinbenton> etc
22:03:32 <armax> kevinbenton: how are you planning to handle FFE requests?
22:03:41 <ihrachys> what's the process? email to openstack-dev?
22:03:46 <kevinbenton> yeah, email to openstack-dev
22:04:07 <armax> well, I used to do it when preparing the postmortem
22:04:12 <kevinbenton> who decided before, the ptl?
22:04:33 <armax> but you’re free to do it differently
22:04:55 <kevinbenton> let me think about it and i'll let you know next week
22:05:41 <kevinbenton> before I forget, let's take a quick look at https://bugs.launchpad.net/neutron/+bug/1705719 because the patches are ready to go
22:05:41 <openstack> Launchpad bug 1705719 in neutron "[RFE] QinQ network driver" [Wishlist,Triaged] - Assigned to Trevor McCasland (twm2016)
22:05:51 <kevinbenton> (well are at least close when i reviewed yesterday)
22:07:09 <ihrachys> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bug/1705719
22:07:49 * armax goes back to the discussion we had last week
22:08:21 <ihrachys> the change will break everyone who based their type drivers on SegmentTypeDriver. smth to consider close to the end of the cycle.
22:09:05 <ihrachys> http://codesearch.openstack.org/?q=SegmentTypeDriver&i=nope&files=&repos=
22:09:26 <ihrachys> bagpipe in the list
22:09:55 <kevinbenton> ihrachys: i'm not sure segmenttypedriver changes with the refactor
22:10:10 <ihrachys> the argument to __init__ changes from db model to OVO
22:10:21 <kevinbenton> oooh
22:10:22 <ihrachys> look here https://review.openstack.org/#/c/483020/3..5/neutron/plugins/ml2/drivers/helpers.py
22:10:24 <kevinbenton> the OVO component
22:11:01 <kevinbenton> ihrachys: don't we need that in the switch to OVO anyway?
22:11:23 <ihrachys> it's a good change, just a churn at the end of cycle, that's all I have to say.
22:11:44 <kevinbenton> ihrachys: i suppose we can put in a compatibility shim if we are worried that detects if what is passed in is OVO
22:11:44 <ihrachys> we'll need to advertise to consumers; prepare patch for bagpipe at least
22:11:54 <ihrachys> I asked about that before in the patch, not sure if any of that happened
22:12:13 <armax> kevinbenton: in the last meeting you said this driver will be used by the srviov mech driver
22:12:41 <armax> but I see no link anywhere
22:13:10 <kevinbenton> armax: i don't think they have that part up yet
22:13:33 <armax> OK, but shouldn’t that be captured somewhere so that we can more meaningfully review the code that’s currently under review?
22:13:40 <armax> what if we screw up the migration?
22:13:45 <kevinbenton> what migration?
22:13:49 <armax> the DB migration
22:14:05 <armax> I mean what if we overlook a detail in the model because we don’t have the full picture
22:14:47 <kevinbenton> so we can't approve the RFE until we see an implementation?
22:14:53 <armax> no
22:14:57 <kevinbenton> i'm fine blocking from merging this cycle
22:14:58 <armax> I didn’t say that
22:15:01 <kevinbenton> if there is no impl
22:15:08 <armax> but the RFE has nothing
22:15:14 <armax> except a skinny description
22:15:32 <armax> no spec either
22:15:34 <kevinbenton> isn't that the point of an RFE?
22:15:55 <kevinbenton> describe the use case
22:16:11 <amotoki> RFE itself is a feature request. If it turns out we need more discussion on the direction of the implemention during review, can't we switch to a blueprint?
22:16:12 <armax> the use case mention nothing of SRIOV
22:16:57 <armax> the RFE’s description is rather inadequate IMO to understand what’s going on
22:17:00 <armax> I quote
22:17:01 <armax> We can implement this by first refactoring VLAN's allocation logic and then extending it to handle a second layer of VLAN tagging. Essentially replacing vlan_id with a s_tag:c_tag pair
22:17:03 <kevinbenton> because that's an implementation detail?
22:17:05 <armax> that’s not even supposed to be in tehre
22:17:16 <armax> OK, ignore me
22:17:45 <kevinbenton> did we lose him?
22:18:06 * ihrachys pulls popcorn closer
22:18:18 <armax> it’s not an implementation detail
22:18:35 <armax> it’s an important part of the end-to-end solution required for the feature being requested
22:18:41 <armax> it helps us understand what documentation is required etc
22:19:23 <kevinbenton> armax: put what you want to see on the RFE and we can come back to it next week when he replies
22:19:51 <armax> well, do you first agree with me?
22:19:56 <kevinbenton> talking about which driver should be supported feels like an implementation detail to me
22:20:00 <armax> otherwise I am not gonna waste my time
22:20:15 <amotoki> agree on armax's point. this is on implementation approach.
22:20:22 <armax> but that defeats the point of the whole RFE process
22:20:34 <armax> which you’re diluting to making it a rubberstamping process
22:20:52 <kevinbenton> armax: no, RFE is IMO a user story thing
22:20:52 <armax> if we go straight to review without even looking at the bigger picture
22:21:03 <armax> dude, have you read the description of the RFE?
22:21:13 <kevinbenton> i don't want to have this conversation again
22:21:38 <kevinbenton> we can ask what driver the implementation needs to be for on the RFE
22:21:49 <kevinbenton> and discuss next week
22:21:51 <armax> for what it’s worth
22:21:58 <armax> I don’t see why we’re even refactoring at this point
22:22:13 <armax> we might as well better off duplicating allocation logic as of now
22:22:26 <armax> as refactoring feels like an early optmization
22:22:35 <armax> that said, I don’t even understand why it’s in the RFE description
22:23:13 <armax> I am somewhat concerned taht we’re shortcutting the process and that may backfire spectacurlarly
22:23:16 <armax> that’s all
22:23:22 <armax> I am voicing my concern
22:23:31 <armax> you seem like annoyed that I do
22:23:42 <armax> so kick me out of the team let’s be done with this farce
22:24:00 <kevinbenton> i don't like RFE's getting too bogged down with implementation details
22:24:07 <kevinbenton> i agree that the mention of the refactor should be removed
22:24:28 <armax> an RFE should describe a use case
22:24:55 <armax> a use case is a description of a step-wise process of interaction between user and system or system to system
22:25:01 <armax> it doesn’t have to have implementation details
22:25:23 <armax> but I see no use case there
22:25:36 <kevinbenton> QinQ encap for isolation of vlans
22:25:37 <armax> if you magically see it, then enlighten us, that’s all I am asking
22:25:57 <armax> OK, never mind
22:26:01 <armax> let’s move on
22:26:10 <kevinbenton> let's you get out of the 4096 limit
22:26:28 <armax> let’s move on
22:26:51 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:27:10 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1604222
22:27:10 <openstack> Launchpad bug 1604222 in neutron "[RFE] Implement vlan transparent for openvswitch ML2 driver" [Wishlist,Triaged]
22:27:26 <kevinbenton> so at this point, I don't think we have anyone to implement this
22:28:20 <kevinbenton> However, IIRC we switched to using push/pop vlan in the OVS agent
22:28:37 <kevinbenton> so once we have a version with qinq support maybe it will magically work?
22:29:09 <kevinbenton> either way, i think this will just have to go to rfe-deferred
22:29:29 <kevinbenton> anyone disagree?
22:30:03 <ihrachys> go for it. we can revive.
22:30:05 <amotoki> I wonder what is the difference between this and QinQ RFE..
22:30:06 <mlavalle> yes let's postpone
22:30:25 <kevinbenton> amotoki: QinQ rfe is neutron allocating the inner and outer tags
22:30:43 <amotoki> kevinbenton: ah I see!
22:30:57 <kevinbenton> this one is just encapsulating whatever the tenant gives in neutron provided encap
22:31:08 <amotoki> QinQ as a big range of labels.
22:32:05 <kevinbenton> yeah
22:32:24 <kevinbenton> amotoki: this is called QinQ because internally OVS needs the support to double-tag
22:32:32 <amotoki> on the other hand, in this rfe, tenants specify inner tag and neutron assign outer tag.
22:32:38 <kevinbenton> yep
22:32:39 <amotoki> i totally understand
22:33:17 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1669630
22:33:17 <openstack> Launchpad bug 1669630 in neutron "Network RBAC acceptance workflow" [Wishlist,Triaged]
22:33:25 <kevinbenton> not sure what state that should go into
22:33:39 <kevinbenton> just postponed until Adrian reaches out with time?
22:33:52 <mlavalle> yes
22:35:00 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1682247
22:35:00 <openstack> Launchpad bug 1682247 in neutron "Neutron should be able to fetch hostkeys for ports" [Wishlist,Triaged]
22:35:26 <kevinbenton> mordred: you happen to be around?
22:35:51 <kevinbenton> I'm thinking we can go to rfe-postponed for now on this one
22:38:39 <mordred> kevinbenton: yes - that's fine - it'll be a little while until I can get to that one again
22:43:25 <mlavalle> he mentioned a couple of weeks ago that he was contemplating an alternative
22:43:25 <mlavalle> so if we don't hear from him, it is reasonable to postponoe
22:44:31 <kevinbenton> thoughts?
22:45:11 <amotoki> sounds good to postpone
22:45:25 <clarkb> kevinbenton: you missed a couple lines from mlavalle but mlavalle is back so will let them replay for you
22:45:25 * mlavalle got disconnected
22:45:47 <kevinbenton> oh, my bouncer might have disconnected as well
22:45:57 <mlavalle> yeah, there was a lag
22:45:59 <clarkb> kevinbenton: yes, excess flood
22:46:02 <kevinbenton> i didn't get anything from anyone since i started blathering
22:46:20 <clarkb> last message was which would obviate the need for this spec then disconnect then connect then thoughts?
22:46:24 <mlavalle> I ended up re-connecting
22:46:34 <kevinbenton> holy crap!
22:46:41 <kevinbenton> i wrote a whole story about another spec
22:46:43 <kevinbenton> :)
22:46:47 <kevinbenton> one sec
22:46:50 <clarkb> kevinbenton: ya whcih you pasted and flooded out
22:47:01 <clarkb> kevinbenton: so you'll need to paste a few lines at a time to avoid being kicked
22:47:18 <kevinbenton> clarkb: i think my bouncer actually had the connection issue and then dumped them all at once
22:47:20 <kevinbenton> ok
22:47:22 <kevinbenton> here it comes
22:47:31 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1689830
22:47:36 <ihrachys> freenode was dead for me for a while, I guess it's everyone
22:47:39 <kevinbenton> So we got more details on https://bugs.launchpad.net/neutron/+bug/1689830
22:47:45 <kevinbenton> use case is that you have multiple tenants on a shared network
22:47:51 <kevinbenton> and they want to run VRRP between their VMs or some kind of IP sharing mechanism like it
22:47:51 <mlavalle> ihrachys: yeah, it wasn't only you
22:47:57 <kevinbenton> so each VM needs to be able to use the shared IP
22:48:02 <kevinbenton> normally you would add this to allowed_address_pairs
22:48:09 <kevinbenton> but currently we block that on shared networks because you can add any address you want to allowed_address_pairs, including those of other tenants' ports
22:48:18 <kevinbenton> So this RFE is to provide a mechanism to only allow addresses that are not in use by other tenants
22:48:27 <kevinbenton> Right now I'm thinking we should just have a separate attribute from allowed address pairs with completely independent API validation/policy
22:48:35 <kevinbenton> To avoid overcomplicating the allowed address pairs code
22:48:40 <kevinbenton> thoughts?
22:48:44 <kevinbenton> (end of message) :)
22:49:47 <openstack> Launchpad bug 1689830 in neutron "[RFE] advanced policy for allowed addres pairs" [Wishlist,Triaged]
22:49:51 <kevinbenton> This might even be a good time to formalize the notion of a port impersonated by another port
22:50:38 <kevinbenton> like an attribute on the port called 'can_impersonate' which takes a list of other port UUIDs
22:50:40 <amotoki> or we can allow to specify a port to allowed-address-pair of another port.
22:51:10 <kevinbenton> amotoki: yeah, i think we're suggesting the same thing
22:51:49 <kevinbenton> by cross referencing another port directly we don't have to worry about stale IPs in allowed address pairs if a tenant deletes the shared port
22:52:32 <kevinbenton> armax: how do you feel about the use case now the submitter clarified?
22:52:39 <mlavalle> and the port specified in allowed address pairs is also owned by the same tenant
22:52:50 <kevinbenton> mlavalle: right
22:52:59 <armax> it’s fine
22:53:04 <kevinbenton> standard forcing tenant match unless your an admin
22:53:12 <mlavalle> correct
22:53:28 <amotoki> mlavalle: do you think a port on a different network can be speciifed?
22:53:41 <amotoki> i am not sure it works well.
22:53:41 <kevinbenton> i think no
22:53:47 <mlavalle> me neither
22:54:02 <amotoki> in a same page
22:54:08 <kevinbenton> let me capture this in the RFE and see if that would work for the submitter
22:54:29 <amotoki> i just confirmed what means by "by the same tenant"....
22:54:29 <kevinbenton> and we can maybe target this for Queens
22:54:59 <kevinbenton> amotoki: yeah, logic would be regular user can only setup a port to impersonate another port on the same network with the same tenant
22:55:46 <mlavalle> that's right
22:55:57 <kevinbenton> agent-side code and backends will need to be updated to read from this new attribute so Pike is unrealistic
22:56:10 <amotoki> kevinbenton: yes. this simplifies a workflow: currently a user needs to crete a port to reserve IP address and specify the IP to allowed-addres-pair.
22:56:27 <mlavalle> amotoki: ++
22:58:04 <kevinbenton> ok, i left a comment
22:58:10 <mlavalle> good
22:58:12 <kevinbenton> we can revisit at next meeting
22:58:20 <kevinbenton> that's all the time we have
22:58:29 <kevinbenton> any last minute announcements or anything?
22:58:36 <mlavalle> not from me?
22:58:42 <kevinbenton> mlavalle: i'm not sure?
22:58:45 <kevinbenton> :)
22:58:49 <mlavalle> I am sure ;-)
22:58:50 <kevinbenton> ok
22:58:55 <kevinbenton> thanks everyone
22:58:55 <mlavalle> LOL
22:58:58 <mlavalle> o/
22:59:06 <kevinbenton> #endmeeting