22:00:47 <mlavalle> #startmeeting neutron_drivers
22:00:48 <openstack> Meeting started Thu Nov  2 22:00:47 2017 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:51 <openstack> The meeting name has been set to 'neutron_drivers'
22:01:31 <yamamoto> hi
22:01:39 <mlavalle> hey
22:02:01 <mlavalle> armax, ihrachys: ping
22:02:01 <ihrachys> o/
22:03:16 <mlavalle> amotoki pinged earlier today. he won't attend today's meeting
22:04:18 <mlavalle> yamamoto, ihrachys: next week armax, amotoki, and me will be most likely travelling back from Sydney
22:04:32 <mlavalle> so maybe we should skip next week's meeting
22:04:43 <mlavalle> I know I will be in an airplane
22:04:57 <ihrachys> of course we should
22:05:11 <mlavalle> ok
22:05:56 <mlavalle> This is the list of RFEs that we have to discuss today: https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:06:19 <mlavalle> The top three have questions to submitters or action items
22:06:47 <mlavalle> So we can start here today: https://bugs.launchpad.net/neutron/+bug/1705536
22:06:49 <openstack> Launchpad bug 1705536 in neutron "[RFE] L3-agent agent-mode dvr bridge." [Wishlist,Triaged]
22:07:52 <mlavalle> POC code is here: https://review.openstack.org/#/c/472289/
22:07:53 <patchbot> patch 472289 - neutron - [POC] Introduction of OpenFlow implementation of DVR.
22:08:28 <ihrachys> really?..
22:09:31 <ihrachys> though I remember some were keen in past meetings to allow yet-another-mode. sigh.
22:09:51 <ihrachys> I am not going to touch this with a long stick
22:10:51 <mlavalle> would you share your concerns ihrachys?
22:11:34 <ihrachys> destabilization of the code base while the team is shrinked and stretched would be the main one
22:12:14 <ihrachys> I don't think we made any progress lately making dvr-ha default and voting in gate
22:12:59 <ihrachys> and even more code churn, I am sure, won't help
22:13:03 <ihrachys> that's all I have
22:13:45 <mlavalle> if DVR jobs were stable, would you think we could consider it in the future?
22:14:29 * mlavalle agrees with the stability concern
22:14:37 <haleyb> too bad we don't have experimental, since a lot of the code is separate
22:15:02 <ihrachys> haleyb, right. I've heard that per-pike :p
22:15:05 <ihrachys> *pre
22:15:22 <ihrachys> about another change, also introducing a bunch of new modes
22:16:07 <haleyb> i have been fighting fires in the l3-agent, and yes, a new mode could be trouble
22:16:08 <ihrachys> mlavalle, I think yes, but it's far from happening
22:16:28 <yamamoto> i'm not sure if i understand the motivation. ie. how it would be better than the existing options like dragonflow.
22:17:29 <mlavalle> ihrachys: I am trying to come up with the correct feedback for the RFE. Is this something we won't consider now until we have proven to ourselvers DVR is stable and controllable?
22:17:40 <mlavalle> or this just something we don't want to do
22:18:14 <mlavalle> yamamoto: the way I understand it is that this would be a flows based router integrated in DVR
22:19:07 <ihrachys> ignoring complexity and missing test scenario coverage, it's a good idea. if we tackle all that, sure we can revisit. but is it a good idea to give someone hope if we let's say believe that it won't happen in next cycle(s)?
22:20:30 <mlavalle> I agree
22:20:35 <ihrachys> yamamoto, they probably don't want to use 3party components
22:21:24 <yamamoto> the famous "not invented here"?
22:21:38 <ihrachys> there is marginal value for a consumer in having something in tree, but it doesn't justify yet another cycle of fighting uphill with dvr gate jobs
22:21:38 <haleyb> can we get some of the base code in place, is that a stretch?
22:21:58 <ihrachys> haleyb, base code?
22:22:08 <mlavalle> what do you mean?
22:22:52 <haleyb> ihrachys: some of the changes, like the router_info_base stuff, isn't invasive, i'm just thinking out loud
22:23:33 <ihrachys> I haven't checked patches. the base code changes are beneficial for what exactly?
22:23:48 <ihrachys> btw the bug doesn't mention any patches
22:24:53 <haleyb> ihrachys: not exactly beneficial, but if we want it exactly it makes for less work to keep carrying separate
22:25:03 <haleyb> s/exactly/eventually
22:26:21 <ihrachys> we would need to see code
22:26:52 <mlavalle> https://review.openstack.org/#/c/472289/
22:26:53 <patchbot> patch 472289 - neutron - [POC] Introduction of OpenFlow implementation of DVR.
22:27:06 <mlavalle> I'll add it to the bug
22:27:23 <mlavalle> done
22:27:35 <mlavalle> So I agree in not approving this
22:27:36 <ihrachys> quick look at _base module suggests it makes general sense
22:28:32 <haleyb> there are some refactors we could do to make it easy in the future, that's all i'm saying
22:28:41 <ihrachys> + for that
22:29:13 <haleyb> land the rest in R1 :)
22:29:36 <mlavalle> Going back to what was said above
22:30:16 * haleyb should have kept his mouth shut, just meant future
22:30:16 <mlavalle> I propose the feedback should be we are not approving this given the instability in DVR jobs
22:30:41 <haleyb> mlavalle: right, we need to get jobs stablized and voting
22:31:07 <mlavalle> and that we might consider it the future after we show a period of stability in DVR
22:31:07 <ihrachys> and we accept blood donations to make it happen
22:31:35 <mlavalle> yamamoto: thoughts?
22:32:39 <yamamoto> i guess the submitter should show us clear reasons why it should be done.
22:33:09 <mlavalle> ok, we can incorporate that in the feedback
22:33:11 <yamamoto> eg. why the existing options are not suitable.
22:33:18 * haleyb has to step out
22:33:40 <haleyb> yamamoto: this gets us better performance for one, that's why i'd do it
22:34:32 <mlavalle> moving on
22:34:41 <mlavalle> https://bugs.launchpad.net/neutron/+bug/1705719
22:34:43 <openstack> Launchpad bug 1705719 in neutron "[RFE] QinQ network driver" [Wishlist,Triaged] - Assigned to Trevor McCasland (twm2016)
22:36:17 <mlavalle> Again there is a series of patchses that start here: https://review.openstack.org/#/c/482307
22:36:17 <patchbot> patch 482307 - neutron - Add QinQ model and object
22:38:45 <ihrachys> that's fine, just a new type driver, and I've heard requests from field people about having it in neutron
22:39:54 <ihrachys> there is some refactoring to do in type_vlan but that is not a scary place in the tree and extensively validated
22:40:43 <mlavalle> that's probably this: https://review.openstack.org/#/c/458531
22:40:44 <patchbot> patch 458531 - neutron - Refactor type_vlan for QinQ compatibility
22:40:52 <yamamoto> i have a trouble to understand how a tenant network would be associated to a set of tags.
22:40:54 <ihrachys> right. there was also a 'OVO' piece
22:41:21 <mlavalle> The ovo piece: https://review.openstack.org/#/c/483020
22:41:22 <patchbot> patch 483020 - neutron - Integrate OVO in helpers
22:41:23 <ihrachys> yamamoto, for what I understood, it will just be allocated dynamically on top of s_tag?
22:41:44 <ihrachys> so s_tag is fixed and c_tag is picked by neutron/admin
22:41:55 <ihrachys> then driver builds frames with both
22:43:10 <mlavalle> that's my understanding, especially after last comment from Trevor
22:44:29 <yamamoto> he said that a physnet can have multiple s_tags. it made me confused.
22:45:29 <ihrachys> "entry for every physnet and s_tag the user wishes to use."?
22:45:40 <ihrachys> I read it as there will be a physnet per s_tag
22:46:02 <ihrachys> physnet1:1:1:1000,physnet2:2:1:1000
22:46:24 <yamamoto> "A physical network can have many s_tags"
22:47:34 <mlavalle> so let's get this clarified
22:47:49 <ihrachys> probably terms conflated - once talking about a NIC another time about neutron physnet abstractions
22:47:55 <ihrachys> + to clarify
22:48:01 <mlavalle> I will leave a message in the RFE
22:49:04 <mlavalle> Moving on
22:49:09 <mlavalle> https://bugs.launchpad.net/neutron/+bug/1705755
22:49:10 <openstack> Launchpad bug 1705755 in neutron "[RFE] Plugin support for API resource attribute extensions" [Wishlist,Triaged]
22:50:38 <mlavalle> I guess here really the next step is a conversation with the OSC team, right?
22:52:11 <yamamoto> what we want to provide is already clear?
22:53:34 <ihrachys> right. someone should pull an answer from OSC folks
22:54:45 <yamamoto> if it's ok to add everything to osc?
22:55:09 <ihrachys> yes
22:55:47 <mlavalle> yamamoto: I'm curious if this is not an issue from Midonet perspective
22:55:58 <mlavalle> midonet is mentioned in the bug
22:56:12 <yamamoto> does "everything" include the infamous extra argument?
22:56:31 <ihrachys> which arg?
22:57:13 <yamamoto> mlavalle: where? i haven't noticed
22:58:10 <mlavalle> yamamoto: it's not, I got confused
22:58:13 <yamamoto> ihrachys: i meant this https://docs.openstack.org/python-neutronclient/latest/cli/neutron.html#cli-extra-arguments
22:59:28 <yamamoto> mlavalle: midonet has some extensions which can't be done via osc, so it's surely affected.
22:59:34 <ihrachys> oh. I don't think it was a plan for OSC to allow random payload. I remember we had it causing lots of issues in neutronclient where the extra handler behaved differently for booleans than legit args
23:00:11 <ihrachys> I don't think the focus of the RFE should be about random payload. instead to establish rules on how neutron apis are added, and which of them are allowed.
23:00:18 <ihrachys> btw time!
23:01:08 <mlavalle> yamamoto: if you have a chance, would you leave some feedback on how this could be solved from your perspective?
23:01:16 <mlavalle> #endmeeting