21:01:56 <kevinbenton> #startmeeting networking
21:01:56 <mlavalle> o/
21:01:58 <openstack> Meeting started Mon May 15 21:01:56 2017 UTC and is due to finish in 60 minutes.  The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:01 <openstack> The meeting name has been set to 'networking'
21:02:20 <haleyb> hi
21:02:24 <dimak_> Hey
21:02:28 <hichihara> hi
21:02:38 <oanson_> Hi
21:02:50 <kevinbenton> #topic Announcements
21:03:03 <kevinbenton> the summit was last week
21:03:23 <kevinbenton> we got some pretty good feedback in the forum sessions
21:03:30 <mlavalle> ++
21:04:11 <kevinbenton> if you attended a forum session, can you please send an email to the list with a link to the etherpad and a short summary with the action items
21:04:13 <Sukhdev> I need to send the summary of the session that I moderated
21:04:30 <kevinbenton> Sukhdev: thanks
21:04:32 <Sukhdev> Will
21:04:37 <kevinbenton> armax: do you have a link to yours handy?
21:05:12 <kevinbenton> here is an example of one from armax
21:05:16 <kevinbenton> #link http://lists.openstack.org/pipermail/openstack-dev/2017-May/116610.html
21:05:22 <mlavalle> kevinbenton: armax sent a couple of messages to the ML over the weekend
21:05:55 <kevinbenton> ok
21:06:14 <kevinbenton> does anyone else have any announcements to make?
21:06:25 <Sukhdev> I have one
21:06:30 <kevinbenton> Sukhdev: go ahead
21:07:02 <Sukhdev> I announced the kick off networki-OpenContrail during the summit
21:07:24 <Sukhdev> Want to make sure everyone is aware of it here as well
21:07:53 <mlavalle> Sukhdev: maybe a message to the ML would be helpful, to reach more people
21:08:21 <Sukhdev> mlavalle: good suggestion... Will do
21:08:48 <kevinbenton> ok, thanks
21:09:05 <kevinbenton> i'll turn it over to boden now to talk about neutron lib since he's time constrained
21:09:09 <kevinbenton> #topic neutron-lib
21:09:12 <boden> hi thanks
21:09:21 <boden> a number of neutron-lib 1.6.0 consumption changes in-progress and more in the pipeline
21:09:31 <boden> for those out already please see the ML notes and:
21:09:39 <boden> #link https://review.openstack.org/#/q/status:open+message:%22NeutronLibImpact%22
21:10:15 <boden> if there are no questions/comments on those, I wanted to bring up one from a few weeks ago
21:10:51 <kevinbenton> boden: the mech lib
21:11:17 <kevinbenton> boden: i would like to leave behind shims for that one if we can
21:11:41 <kevinbenton> boden: since we have been taking an effort to make the mech driver API quite stable
21:12:09 <boden> kevinbenton: well a lot of people already switched
21:12:10 <boden> https://review.openstack.org/#/q/message:%22use+MechanismDriver+from+neutron-lib%22
21:12:17 <boden> but sure
21:12:28 <boden> can we take that discussion to the patch?
21:12:37 <boden> https://review.openstack.org/#/c/462731/
21:12:44 <kevinbenton> yep
21:12:49 <kevinbenton> i just want to make sure
21:13:04 <kevinbenton> we aren't causing too much churn just to avoid a few lines of imports in neutron that pass through
21:13:18 <kevinbenton> particularily with the development resource shortage in general around neutron projects
21:13:21 <boden> kevinbenton: have peopel been yelling at you about this one?
21:13:59 <kevinbenton> boden: not that one in particular, just lots of the little import changes build up for people that can't keep up with trunk development
21:14:04 <boden> ack
21:14:19 <boden> that plays into my next topic/question
21:14:25 <boden> about 3 weeks ago we started the transistion to neutron-lib callbacks and a note was sent to the ML (http://lists.openstack.org/pipermail/openstack-dev/2017-April/115924.html)
21:14:34 <boden> there are still a number of consumers who have not swtiched: http://codesearch.openstack.org/?q=from%20neutron.callbacks
21:14:41 <boden> how long do we wait before removing callbacks from neutron?
21:15:53 <kevinbenton> boden: let's just wait until last milestone
21:15:59 <kevinbenton> so another couple of months
21:16:17 <kevinbenton> it's not blocking anything is it?
21:16:48 <mlavalle> why not, midway through those 2 months, send a reminder to the ML stating what the hard deadline is?
21:17:26 <boden> kevinbenton: not aware of it blocking anything… IIUC the new “payload” api can be used now; so I could start on that work as-is
21:18:35 <kevinbenton> boden: right, it shouldn't block any development in neutron-lib
21:18:44 <boden> anyway: sounds like we want to wait a bit… I can bring the topic up again in a later meeting
21:19:01 <kevinbenton> boden: +1
21:19:05 <boden> I don’t have anything else
21:19:12 <kevinbenton> ack
21:19:31 <kevinbenton> #topic bugs
21:19:38 <kevinbenton> who was bug deputy last week?
21:20:04 <mlavalle> I think janzian was the week before
21:20:05 <janzian> I was for the week leading up to the summit, but not sure who came after me
21:20:26 <kevinbenton> ah, we didn't have a meeting to assign one :)
21:20:57 <kevinbenton> i can go through the backlog and be bug deputy for this week
21:22:29 <kevinbenton> #topic liaisons
21:23:01 <kevinbenton> we need a new oslo liaison
21:23:14 <kevinbenton> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons
21:24:01 <kevinbenton> it's pretty simple, just keep an eye on the oslo mailing list for changes that might impact neutron
21:25:08 <kevinbenton> we also need a docs person
21:25:56 <janzian> kevinbenton: I can handle oslo liaison
21:26:03 <kevinbenton> janzian: thanks
21:26:13 <kevinbenton> janzian: can you update that wiki to add your name and IRC handle?
21:26:40 <janzian> kevinbenton: Sure thing, will do
21:27:09 <kevinbenton> To make docs a little more manageable I think there is some work to bring the docs into the neutron tree so we can have a hard requirement to at least get something in place for docs before merging patches
21:27:38 <kevinbenton> but I need to sync up with the docs folks to see the status of that
21:27:56 <mlavalle> kevinbenton: if you have to much work, I can handle that
21:28:02 <Sukhdev_> kevinbenton : one of the feedback from the session I moderated was that we need to document a bit better
21:28:18 <mlavalle> kevinbenton: I just don't to hog those liasions positions
21:28:41 <mlavalle> I think we need to give opportunity to new people
21:28:56 <mlavalle> but, in the meantime, if things are urgent, I can help
21:29:01 <kevinbenton> mlavalle: it would be good if you can take the role for now
21:29:16 <mlavalle> ack
21:29:34 <kevinbenton> mlavalle: but i think we should force our devs to write some basic docs for things
21:29:42 <mlavalle> yeap
21:29:54 <haleyb> i can help as well
21:30:03 <kevinbenton> haleyb: thanks
21:30:07 <mlavalle> haleyb: great
21:30:27 <kevinbenton> #topic Open Discussion
21:30:42 <kevinbenton> does anyone have anything else to bring up?
21:31:04 <kevinbenton> I'm still going through a bunch of action items from the summit so expect to see emails from me throughout the week as well with summaries of sessions and whatnot
21:31:10 <mlavalle> I think dimak_ has a topic
21:31:24 <kevinbenton> dimak_: go ahead
21:31:32 <dimak_> Yeah, following up the DVR forum session
21:32:23 <dimak_> I think we can make some progress using dragonflows SNAT solution
21:33:15 <kevinbenton> dimak_: well the issue wasn't that we didn't have potential solutions
21:33:32 <kevinbenton> we just don't have the development bandwidth to make those changes in Neutron
21:33:44 <kevinbenton> at least it doesn't look like it for Pike
21:34:53 <kevinbenton> dimak_: does that make sense?
21:35:06 <dimak_> kevinbenton, yeah
21:36:15 <dimak_> It was mentioned making df's snat part of l3 flavor
21:36:26 <dimak_> I'm not sure we can do that easily with current architecture
21:37:08 <kevinbenton> dimak_: if you can identify gaps in l3 flavors to enable that we can definitely make changes
21:38:01 <oanson_> We'll have to look into it. Currently the snat solution is heavily integrated into DF architecture
21:39:13 <kevinbenton> well the l3 flavors would just be to allow DF to run side-by-side as an alternative to DVR
21:39:52 <oanson_> That means another service in the compute node (The DF controller)
21:40:04 <dimak_> It will have to run a stripped down df agent that does just that
21:40:04 <kevinbenton> oanson_: right
21:40:42 <dimak_> And it will require deployment of a database for DF (at least at the moment)
21:41:30 <kevinbenton> dimak_: not quite, the l3 flavors approach would be fully adopting DF for routers
21:42:01 <kevinbenton> with that flavor
21:42:34 <oanson_> How is policy installed in this case? How is the information passed to the routers?
21:43:41 <oanson_> This is what the DB is for - it stores the objects and policies used to build the network features
21:45:15 <kevinbenton> yes
21:45:24 <kevinbenton> l3 flavors is just a way to have multiple l3 plugins essentially
21:45:33 <kevinbenton> with some routers assigned to 1 plugin
21:45:38 <kevinbenton> and others assigned to a different one
21:45:51 <kevinbenton> it's not a way to just adopt some features from one plugin and some from another
21:46:14 <kevinbenton> so if dragonflow has an l3 flavor service provider
21:46:28 <kevinbenton> the routers associated with that will just be using dragonflow as it is today
21:46:32 <oanson_> Dragonflow has an L3 plugin and implementation.
21:46:38 <oanson_> So in this scenario, Dragonflow will replace e.g. DVR?
21:46:49 <mlavalle> would live side by side with it
21:47:02 <kevinbenton> users would pick a flavor
21:47:09 <kevinbenton> when creating a router
21:47:22 <kevinbenton> e.g. "fully distributed" would go to dragonflow
21:47:48 <kevinbenton> while "centralized SNAT" would go to DVR
21:47:56 <kevinbenton> l3 flavors is very similar to ML2
21:48:11 <oanson_> ok, I think I get it.
21:48:28 <oanson_> So if we want to do that, what do we have to do?
21:49:06 <kevinbenton> oanson_: implement a "dragonflow" service provider
21:49:13 <mlavalle> we need an L3 flavor service provider
21:49:35 <mlavalle> in dragonflow
21:49:54 <kevinbenton> the difficult part will be if you implemented special extensions
21:50:14 <kevinbenton> l3 flavors doesn't currently have a way for different providers to introduce extensions
21:50:57 <Sukhdev_> I think we need some kind of network policy extension in L3 to accomodate it
21:51:29 <kevinbenton> Sukhdev_: network policy extension?
21:52:16 <Sukhdev_> right - which allows different plugins to implement different routing techonologies in the backend
21:52:31 <Sukhdev_> existing plugins will ignore it DF can implement it
21:53:13 <kevinbenton> Sukhdev_: an API that only works with some backends and has no effect on others is bad for users
21:53:55 <Sukhdev_> kevinbenton : right - that will be the shortcoming of this approach -
21:54:16 <Sukhdev_> but, other plugins may want it down the road -
21:54:28 <mlavalle> kevinbenton, oanson_, dimak_: if we want to explore this further, I can help from the Neutron side. I am not sure we can do it in Pike, but we can get it rolling
21:55:16 <kevinbenton> oanson_: if you introduce extensions in your l3 plugin, it would be good if you can let me know what they do
21:55:29 <kevinbenton> oanson_: and then we can make adjustments to l3 flavors for any gaps as necessary
21:55:36 <oanson_> Currently all our extensions are based on Neutron APIs.
21:55:40 <Sukhdev_> oanson_ : I would be interested to know this as well
21:56:27 <kevinbenton> oanson_: so you don't add any additional ones?
21:56:44 <oanson_> No. We tried to stick the Neutron API.
21:57:03 <kevinbenton> oanson_: perfect, you should be able to write a service driver then
21:57:20 <mlavalle> ++
21:57:34 <dimak_> kevinbenton, we'll see how easy it can be done with dragonflow as it is
21:57:40 <kevinbenton> ok, well we are out of time
21:57:41 <dimak_> not sure we can manage it in pike either
21:58:13 <kevinbenton> oanson_, dimak_: if you hit any issues/questions with l3 flavors, shoot an email to openstack-dev
21:58:30 <dimak_> will do
21:58:50 <kevinbenton> ok
21:58:52 <kevinbenton> thanks everyone
21:58:59 <oanson_> Thanks
21:59:02 <kevinbenton> #endmeeting