22:00:05 <mlavalle> #startmeeting neutron_drivers
22:00:06 <openstack> Meeting started Thu Nov 16 22:00:05 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:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:09 <openstack> The meeting name has been set to 'neutron_drivers'
22:00:21 <mlavalle> hi there!
22:00:24 <yamamoto> hi
22:00:54 <ihrachys> o/
22:01:15 <mlavalle> armax: ping
22:02:07 <mlavalle> let's wait a couple of minutes to see if amotoki and armax join
22:02:19 <mlavalle> and don't see amotoki on line, though
22:02:54 <mlavalle> yamamoto: did the local time of the meeting change for you?
22:03:09 <yamamoto> no
22:03:29 <ihrachys> they don't move tz
22:03:35 <ihrachys> smart of them
22:03:41 <mlavalle> is this good for you, ihrachys?
22:03:49 <ihrachys> it's ok, it's better
22:03:57 <mlavalle> cool
22:04:31 <mlavalle> ok, let's get going
22:04:47 <mlavalle> This is what we have for today
22:04:53 <mlavalle> https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:05:59 <mlavalle> First one is https://bugs.launchpad.net/neutron/+bug/1690425
22:05:59 <openstack> Launchpad bug 1690425 in neutron "[RFE] neutron cells aware" [Wishlist,Triaged]
22:06:29 <mlavalle> I had a conversation with GoDaddy about this on this flying back from Sydney
22:06:40 <mlavalle> with Chris
22:07:39 <mlavalle> the summary of it is that he would see a lot of benefir if we were able to improve the performance of the RPC bus
22:08:52 <mlavalle> by using message routing like suggested by armax in #5
22:09:03 <mlavalle> comment^^^
22:09:47 <mlavalle> but he also says they would see a lot of benefit in Neutron in moving Neutron to a configuration where cells would be reflected in Neutron
22:09:58 <ihrachys> mlavalle, I haven't seen the video. is it some new driver in oslo.messaging? not rabbit?
22:09:58 <mlavalle> for failure domain isolaion pruposes
22:10:21 <mlavalle> ihrachys: I don't think it is in oslo yet
22:10:50 <mlavalle> the presentation was more of the general concept of the approach
22:11:56 <ihrachys> I'll watch the video some day later
22:12:16 <mlavalle> so maybe the next step is to update the RFE with the comments from GoDaddy
22:12:48 <mlavalle> and ping other large deployers, like CERN and seek their feedback
22:12:58 <mlavalle> and revisit in a futuire meeting
22:13:02 <mlavalle> thoughts?
22:13:05 <ihrachys> +
22:13:22 <yamamoto> how was "Cells V2 update and direction" forum?
22:13:53 <mlavalle> it was more of very tactical issues that they have found in deployments
22:14:24 <mlavalle> there is no real change in the way they are implemented
22:15:03 <mlavalle> in fact they used the same high level architecture I posted in comment #8
22:15:18 <mlavalle> so we should continue using that as reference
22:15:35 <mlavalle> does that answer the question, yamamoto ?
22:15:42 <yamamoto> yes thank you
22:16:00 <mlavalle> ok, let's move on
22:16:33 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1692490
22:16:33 <openstack> Launchpad bug 1692490 in neutron "[RFE] Ability to migrate a non-Segment subnet to a Segment" [Wishlist,Triaged]
22:17:34 <mlavalle> Harald responded to the questions posted last time we discussed this RFE
22:17:51 <mlavalle> based on those responses I think the RFE is feasible
22:18:11 <mlavalle> and makes sense
22:18:49 <ihrachys> yes, makes sense to provide a way to enable new feature for existing resources
22:19:37 <yamamoto> +1
22:19:50 <mlavalle> so I think we can approve it
22:20:52 <mlavalle> ihrachys: do you know if Harald will work on the implementation?
22:21:08 <ihrachys> no idea, I don't know him at all (I think I don't)
22:21:23 <mlavalle> cool, I'll ask in the RFE
22:22:28 <mlavalle> done
22:23:30 <mlavalle> I'll skip the next one, becuase poster didn't respond to the clarifying questions we asked last time
22:23:43 <mlavalle> so the next one to discuss here is https://bugs.launchpad.net/neutron/+bug/1705536
22:23:43 <openstack> Launchpad bug 1705536 in neutron "[RFE] L3-agent agent-mode dvr bridge." [Wishlist,Triaged]
22:24:12 <mlavalle> We discussed this one with David this morning during the L3 sub-team meeting
22:24:36 <yamamoto> don't you remove "rfe" tag from approved one?
22:24:56 * mlavalle will do that in a minute, forgot
22:25:17 <mlavalle> David understood the reasons to postpone it
22:25:38 <mlavalle> In fact, David and other Intel guys won't be working on OpenStack anymore
22:25:48 <mlavalle> that includes Sean K Mooney
22:26:14 <ihrachys> oh
22:26:27 <mlavalle> however the L3 subteam wants to keep this as a possibility for the future, once we stabilize DVR jobs
22:26:44 <mlavalle> so I'll mark it as delayed
22:27:08 <mlavalle> postponed I meant
22:27:41 <mlavalle> any comments?
22:27:47 <ihrachys> that's good
22:28:01 <yamamoto> its fine
22:28:52 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1705719
22:28:52 <openstack> Launchpad bug 1705719 in neutron "[RFE] QinQ network driver" [Wishlist,Triaged] - Assigned to Trevor McCasland (twm2016)
22:29:17 <mlavalle> I don't think Trevor answered to questions
22:29:42 <mlavalle> I don't have anything to say at the moment until we get a response
22:29:50 <mlavalle> do others have comments?
22:30:19 <ihrachys> no
22:30:39 <yamamoto> no
22:30:56 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1705719
22:30:56 <openstack> Launchpad bug 1705719 in neutron "[RFE] QinQ network driver" [Wishlist,Triaged] - Assigned to Trevor McCasland (twm2016)
22:31:04 <ihrachys> time loop!
22:31:24 <mlavalle> ups
22:31:43 <mlavalle> this is the one https://bugs.launchpad.net/neutron/+bug/1705755
22:31:43 <openstack> Launchpad bug 1705755 in neutron "[RFE] Plugin support for API resource attribute extensions" [Wishlist,Triaged]
22:32:01 <mlavalle> amotoki left a lengthy comment in #14
22:32:31 <mlavalle> addressing the long, medium and short term form his point of view
22:33:27 <mlavalle> not only from client point of view but also API
22:34:08 <ihrachys> "Ideally all vendor API extensions are upstreamed defined in neutron-lib, but this is perhaps not acceptable though."
22:34:19 <ihrachys> I am not sure what we are talking about here. api definitions?
22:34:37 <ihrachys> aren't we moving everything in stadium into the lib right now
22:35:03 <mlavalle> yeah, but I think he also referes to non-stadium
22:35:18 <mlavalle> which is what triggered this RFE, IIUC
22:35:51 <ihrachys> oh ok
22:36:12 <ihrachys> and they can't contribute those extensions to neutron-liB?
22:36:39 <mlavalle> at least that is the assumption that is being made
22:37:42 <mlavalle> so maybe we should ask that question in the RFE as next step
22:37:53 <mlavalle> why not add all those extensions to the lib?
22:38:09 <ihrachys> yeah. first probably to understand what those apis are about.
22:38:21 <ihrachys> maybe it's something silly, very vendor specific
22:38:27 <mlavalle> yeah
22:38:38 <mlavalle> and the good thing as that boden is the submitter
22:38:52 <mlavalle> he must have a good insight on that
22:39:02 <ihrachys> but in general, I was hoping that consolidation of apis in neutron-lib would open doors to us closing the api extensibility hole
22:39:42 <ihrachys> it may break a few but it doesn't seem the list of affected projects is too long
22:39:57 <ihrachys> vmware and cisco and bigswitch are probably the most popular
22:40:05 <mlavalle> which I think is what amotoki suggests ultimately
22:40:07 <ihrachys> so we could have a look at what they extend
22:40:14 <mlavalle> ++
22:40:40 <ihrachys> total agreement that --extra shouldn't be supported in any way
22:41:50 <mlavalle> yamamoto: thoughts?
22:43:24 <yamamoto> it sounds reasonable.  i haven't finished reading amotoki's long comment though.
22:44:01 <mlavalle> I suggest adding a comment there suggesting addition of all those extensions to the lib's api definition
22:44:11 <mlavalle> and see what comments we get back
22:44:50 <mlavalle> agree?
22:45:06 <ihrachys> yeah, also explaining that they may face problems extending neutron api in the way they do in the future
22:45:13 <ihrachys> so that they have a motive to look into it
22:45:25 <mlavalle> yeah, there will be a price
22:45:55 <mlavalle> they won't be on their own anymore and that has benefits but also costs
22:46:30 <yamamoto> agree
22:46:36 <mlavalle> cool
22:46:41 <mlavalle> let's move on
22:47:12 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1715386
22:47:12 <openstack> Launchpad bug 1715386 in neutron "[RFE]Support routing traffic based on subnet" [Wishlist,Triaged]
22:47:12 <yamamoto> maybe we should ask vendors as well?  i guess they are not following the rfe.
22:47:31 <ihrachys> yamamoto, + I think that was part of the plan. if not, let's make it.
22:47:32 <mlavalle> yamamoto: yes, we should do that
22:48:00 <ihrachys> ask every vendor to list their apis and explain why they need them and what they do
22:48:17 <mlavalle> yeap
22:49:43 <mlavalle> to make sure we all turned the page, next one is https://bugs.launchpad.net/neutron/+bug/1715386
22:49:43 <openstack> Launchpad bug 1715386 in neutron "[RFE]Support routing traffic based on subnet" [Wishlist,Triaged]
22:50:17 <armax> shoot, I got the timezone wrong!
22:50:27 <mlavalle> armax: welcome
22:50:39 <armax> I guess I am too late :)
22:50:43 <mlavalle> to Standard Time
22:50:57 <mlavalle> well, 10 minutes to go
22:51:11 <mlavalle> where we can enjoy yor company
22:51:14 <mlavalle> :-)
22:51:19 <armax> I brought cookies
22:52:21 <ihrachys> I am not following the rfe. so they want multiple gateways per router, and then somehow specify (on subnet?) which to use?
22:52:46 <mlavalle> no, it is about routing traffic based on the source
22:53:39 <mlavalle> and in the future, maybe, based on that, generalize the mechanism to do policy based routing
22:53:56 <ihrachys> mlavalle, so it's configured on router
22:54:02 <mlavalle> correct
22:54:12 <armax> from the simplest point of you you can simply hit a different gateway based on the nature of the traffic or the source
22:54:13 <ihrachys> and how do we define where traffic goes? I presume it's multiple gateways?
22:54:27 <armax> there’s different ways in which you can do that with iptables for instance
22:54:40 <armax> I think the way to abstract this via the API is gonna be tricky
22:54:51 <armax> that’s why I suggested the flavor approach
22:55:10 <armax> wehre you can embed the policy rules in the router itself and hide the implementation to the user
22:55:23 <ihrachys> ok, so we could first allow multiple gateways (and round robin them); then as another step, allow to pick one based on traffic pattern / source
22:55:52 <armax> ihrachys: think about this one
22:55:53 <armax> http://www.linuxhorizon.ro/iproute2.html
22:56:25 <armax> in this example the routing is done based on the type of traffic
22:56:37 <armax> rather where the traffic is coming from
22:56:52 <armax> but the concept doesn’t change
22:56:56 <armax> it’s the rules that change
22:57:01 <mlavalle> yeap, same concept
22:57:22 <armax> I think what I find challenging here is how to come up with a high level abstraction to capture the policy rule
22:57:36 <armax> but at the same time powerful enough that you can do something useful with it
22:57:44 <ihrachys> classifier may give the model to describe traffic
22:57:55 <armax> so my main concern is not so much on the implementation but on how to express the policy rules
22:58:27 <armax> I proposed the author to submit a spec so that we can have a better idea of the scope
22:58:32 <armax> they intend to shoot for
22:59:05 <armax> if they are simply interested in bakin a solution into neutron without coming up with a high level API then I think this is doable today already
22:59:13 <mlavalle> maybe if we agree on the concept, approve the rfe and request a spec to see the details
22:59:36 <armax> I’d say the rfe should be approved on the basis of how the work looks like
22:59:46 <armax> otherwise it feels like signing a blank check :)
22:59:54 <mlavalle> fair enough
22:59:54 <armax> 1 min to the top of the hour
23:00:05 <mlavalle> and the work meaning the spec?
23:00:10 <armax> yeah
23:00:21 <armax> the proposed approach is important
23:00:26 <armax> I htink the use case is valid
23:00:26 <mlavalle> thoughts from others?
23:00:40 <armax> how we go about it
23:00:44 <armax> it’s to be agreed
23:00:48 <mlavalle> yeap
23:00:55 <ihrachys> ok to wait for spec. hopefully will clarify things I don't get for me.
23:01:07 <mlavalle> cool
23:01:13 <mlavalle> time is over
23:01:15 <armax> OK
23:01:19 <mlavalle> thanks for attending
23:01:21 <armax> sorry for missing the bulk of the meeting
23:01:26 <armax> ttyl
23:01:28 <mlavalle> see you next time
23:01:30 <ihrachys> o/
23:01:34 <armax> bye
23:01:34 <mlavalle> #endmeeting