16:05:43 <rkukura> #startmeeting networking_ml2
16:05:45 <openstack> Meeting started Wed May 17 16:05:43 2017 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:05:49 <openstack> The meeting name has been set to 'networking_ml2'
16:05:59 <sadasu> Sukhdev: that must have been right after I gave up trying to wave to you :-)
16:06:05 <rkukura> #topic Agenda
16:06:07 <sadasu> now we are even!
16:06:17 <Sukhdev> sadasu :-)
16:06:29 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_May_17.2C_2017
16:07:09 <rkukura> So I changed the agenda a bit for today
16:07:15 <rkukura> Anyone want to add anything specific?
16:07:50 <rkukura> #topic Announcements
16:07:52 <trevormc> 'ML2 meeting format/usefulness/goals etc.' probably fits my topic
16:08:11 <rkukura> trevormc: OK, we’ll get to that in a bit
16:08:24 <rkukura> I don’t have any Announcements - does anyone else?
16:08:48 <trevormc> or maybe it fits better here.
16:09:01 <trevormc> i just wanted to say I'm breaking up my RFE for the sr-iov port extension
16:09:12 <trevormc> I plan to do 5, there are two available now.
16:09:21 <trevormc> https://bugs.launchpad.net/neutron/+bug/1690921
16:09:22 <openstack> Launchpad bug 1690921 in neutron "[RFE] Manage Broadcast, Unicast, and Multicast traffic" [Undecided,New]
16:09:26 <trevormc> https://bugs.launchpad.net/neutron/+bug/1690937
16:09:27 <openstack> Launchpad bug 1690937 in neutron "[RFE] Support allowed address pairs without ip address" [Undecided,New]
16:09:45 <Sukhdev> trevormc : excellent idea
16:09:48 <trevormc> Those two were simple, the next three are more complicated.
16:10:01 <trevormc> 3. VLAN filtering is a technique for preventing communication between hostX and hostY but why do we need this at the port level and not just the network level? QinQ is VLAN based so I think it should work inherently.
16:10:26 <trevormc> - this was just a question i had addressing the third RFE for VLAN Filtering.
16:10:38 <trevormc> 4. Tap-as-a-service – All I know is that it’s a service for mirroring remote ports. Munish said to make it work with direct ports. Can we explain why we would want that from our customer’s perspective?
16:10:51 <trevormc> - this is the mirror from the RFE
16:11:01 <trevormc> 5. Only push or only pop VLAN tags – This has something to do with the QinQ networks, can we elaborate the usefulness of only pushing or only popping?
16:11:24 <trevormc> - currently neutron support both push/pop or neither and not individually
16:12:03 <trevormc> that's all my announcements, expect to see more updates on 3,4 and 5 next week
16:12:57 <rkukura> trevormc: thanks!
16:13:03 <Sukhdev> trevormc : you have a busy agenda -
16:13:10 <trevormc> yes please help
16:13:12 <trevormc> :)
16:13:26 <Sukhdev> trevormc : shall we cover one at a time ?
16:13:28 <trevormc> - not asking for it, just would be nice. thats all
16:13:48 <rkukura> fine with me
16:14:03 <trevormc> Yeah if you have any answers for 3,4, and 5 that would be appreciated and I can incorporate that into the RFE
16:14:16 <trevormc> I have a call next week to discuss these in detail with the research team at AT&T
16:14:43 <Sukhdev> rkukura : why don't you go through the agenda and when you feel is the time, we can start discussing these
16:15:06 <rkukura> OK
16:15:18 <trevormc> sounds good
16:15:20 <rkukura> #topic Sumit recap
16:15:40 <rkukura> So I was only at the summit for a couple hours
16:15:45 <rkukura> How was it?
16:16:15 <rkukura> Was hoping to at least get to the Fenway party
16:16:42 <Sukhdev> I was presenter in two presentation, moderator in one session, and panelist in one panel discussion - so, very busy :-)
16:17:02 <rkukura> sounds like it
16:17:13 <Sukhdev> rkukura : you did not miss much at fenway - it was underwhelming
16:17:21 <sadasu> I felt that the rumors about decline in open stack relevance are false
16:17:43 <rkukura> sadasu: that’s good to here
16:17:44 <sadasu> rkukura: I agree with Sukhdev's version of fenway party
16:17:45 <rkukura> hear
16:18:02 <rkukura> Fenway probably would have been more fine in nice spring weather
16:18:11 <rkukura> s/fine/fun/
16:18:13 <Sukhdev> sadasu : please elaborate
16:18:14 <rkukura> can’t type today
16:18:34 <Sukhdev> rkukura is hungry :-)
16:19:04 <sadasu> Sukhdev: the underwhelming part..I spent a lot of time standing in line outside :(
16:19:05 <trevormc> I went to fenway when the line died down, they ran out of food and drink tickets but I was able to find plenty on the ground or from kind stackers
16:19:27 <trevormc> ~ 1 hour after it started
16:19:28 <Sukhdev> sadasu : i meant the openstack relevence part
16:19:32 <rkukura> sadasu: Were these “rumors” at the summit itself, or just in general?
16:20:03 <rkukura> trevormc: sounds like it was well-attended then
16:20:26 <sadasu> In general, especially after all the news about several companies reducing their open stack developer foot print
16:20:59 <sadasu> no rumors within the summit
16:21:10 <Sukhdev> I heard Cisco has also pulled out or reduced - is it true sadasu, rkukura ?
16:21:18 <rkukura> sounds to me like its evolving, but not really declining
16:21:21 <sadasu> but, definitely a lot of attention on open stack working in tandem with kubernetes
16:21:39 <trevormc> sadsu: I think that's it, the work intersects.
16:21:51 <sadasu> rkukura: I agree
16:21:56 <trevormc> sadsu: not so much pulling away from openstack, just spreading the workload
16:22:34 <Sukhdev> I see kubernetes as an infrastructure to run openstack on - which means it is not going away
16:23:08 <sadasu> Sukhdev: not pulled out, changing focus to other open stack related solutions
16:23:39 <Sukhdev> openstack is perceived to be pain to deploy - kubernetese makes it easy to deploy
16:24:14 <Sukhdev> openshift was in limelight as well
16:24:21 <sadasu> open stack will still be used to abstract cloud HW for other cloud orchestration solutions to use
16:24:37 <Sukhdev> sadasu  +1
16:25:45 <rkukura> So anything neutron-specific from the summit to discuss? How were the forum sessions?
16:26:19 <Sukhdev> I moderated on - two take aways from that session ( I will post it on ML later today)
16:26:46 <Sukhdev> 1) IP address allocation needs attention - for default configurations (can be simplified)
16:27:13 <Sukhdev> 2) documentation can be improved - especially for default configurations
16:28:00 <Sukhdev> #link: https://etherpad.openstack.org/p/pike-neutron-making-it-easy
16:28:40 <rkukura> Thanks Sukhdev!
16:28:54 <rkukura> That’s the one session I attended, I think
16:28:57 <rkukura> Any useful design/planning discussions for pike and beyond?
16:30:53 <rkukura> Or are those sessions only at PTGs now?
16:31:36 <Sukhdev> I think that is PTG agenda
16:32:16 <rkukura> OK
16:32:37 <rkukura> Anything else to share on the summit before we move on?
16:33:08 <trevormc> there is a talk on diagnostic tools, i thought was cool but didnt understand
16:33:20 <trevormc> armando posted something on the ML about it this week
16:33:52 <rkukura> trevormc: Saw that
16:35:16 <rkukura> I had a quick chat with kevinbenton about my extension semantics enforcement RFE - its on hold until either I have time to implement it, or someone else volunteers
16:36:12 <rkukura> ok, lets move on…
16:36:23 <rkukura> #topic ML2 meeting format/usefulness/goals etc.
16:36:59 <rkukura> So post-summit seemed like a good time to revisit what we do at these ML2 meetings
16:37:14 <sadasu> seems to me that several features are currently under development, so why this question about usefulness?
16:37:31 <rkukura> There are only a few of us that attend and participate on a regular basis
16:38:11 <sadasu> rkukura: I think that is the new reality in open stack :-)
16:38:27 <rkukura> One thing we do is discuss status of ongoing ML2-related efforts, such as trevormc’s
16:38:31 <sadasu> smaller teams in general everywhere, what do other's think?
16:38:52 <sadasu> rkukura: +1
16:38:55 <rkukura> I find those status/issue discussions useful, but want to make sure others do
16:39:30 <rkukura> I’d find them more useful if I was more engaged in the actual development and code reviews than I have been lately
16:40:09 <Sukhdev> right
16:40:30 <rkukura> I meant to say “even more useful”, I do find them useful
16:41:16 <trevormc> are there any suggestions to get others involved?
16:42:34 <Sukhdev> I could bring it up in the neutron core meeting next time -
16:42:34 <rkukura> trevormc: looking for those
16:43:01 <trevormc> There are conflicting groups too, like the sr-iov team meetings.
16:43:12 <rkukura> I’d like to figure out how this meeting should relate to the core meeting, and others as well
16:43:25 <trevormc> I didn't really hear about the ML2 meeting until I stumbled upon it, maybe we should do a better job advertising?
16:43:45 <rkukura> One focus here would be actual evolution of the ML2 driver APIs, but there isn’t much of that going on at the moment
16:43:59 <trevormc> yet *cough
16:44:39 <trevormc> I'm hoping we can get some ml2 development with adoption of gluon
16:45:24 <trevormc> that would be an evolution because we would like to adopt Sukhdev's RFE for making the neutron network port-binding optional.
16:45:36 <rkukura> trevormc: I’m not really clear if gluon is seen as something driving evolution of ML2, co-existing with ML2, or replacing ML2
16:46:28 <trevormc> rkukura: we were thinking of making it a core plugin
16:46:48 <trevormc> then seperating out the service-plugin-generator part. This will allow for multiple SDN controllers.
16:47:05 <trevormc> not sure how much evolution at the ML2 there may be but there might be some.
16:47:22 <Sukhdev> trevormc : did you watch my presentation on gluon and attended the panel discussion on Gluon ?
16:47:40 <trevormc> Sukhdev, I couldn't find it. What's it called?
16:47:51 <trevormc> probably something with gluon in the title.. :)
16:48:02 * trevormc searches
16:48:10 <rkukura> were these last week?
16:48:31 <rkukura> I’d definitely like to check them out
16:48:54 <trevormc> nothing with gluon in the title
16:49:07 <trevormc> for this forum anyway
16:49:21 <Sukhdev> rkukura : yes
16:49:49 <Sukhdev> trevormc : both were on Thursday -
16:50:09 * trevormc checks summit schedule
16:50:39 <trevormc> https://www.openstack.org/summit/boston-2017/summit-schedule/events/18826/gluon-project-within-openstack
16:51:15 <Sukhdev> right that - was panel discussion
16:51:29 <Sukhdev> the presentation was the first session on Thursday AM
16:51:58 <yamamoto_> this? https://www.openstack.org/videos/boston-2017/a-novel-service-modeling-framework-for-nfv-networking
16:52:07 <sadasu> Sukhdev: will take a look
16:52:08 <trevormc> https://www.openstack.org/summit/boston-2017/summit-schedule/events/17693/a-novel-service-modeling-framework-for-nfv-networking
16:52:09 <Sukhdev> yamamoto_ : yes, thanks
16:52:27 <trevormc> great, ill watch these on youtube if the video is available
16:52:40 <rkukura> thanks, I will too
16:53:02 <rkukura> so regarding the development efforts, such as trevormc’s, and the ML2 meetings
16:53:13 <Sukhdev> So, one thing I did not announce  (I should have when rkukura asked) I just kicked off networking-opencontrail
16:53:40 <trevormc> \o/
16:53:51 <trevormc> very cool
16:53:55 <rkukura> Do we want to continue with these explicitly on each week’s agenda, or just have a section where people update status and raise questions/issues on ongoing development?
16:54:16 <Sukhdev> networking-opencontrail will be similar to networking-odl/ovn/etc... to open source opencontrail
16:54:53 <Sukhdev> this will require very intense ML2 discussions - we can use this meeting for those or I was thinking about creating a new channel and meeting for that
16:55:15 <rkukura> Sukhdev: I think that would be appropriate to discuss here
16:55:27 <rkukura> Since it would likely impact other ML2 drivers as well
16:55:41 <sadasu> Sukhdev: rkukura: +1 for here
16:55:54 <Sukhdev> rkukura : that will be right in the middle, center, and, everywhere in ML2
16:56:18 <rkukura> Sukhdev: Is networking-opencontrail a git repo and/or a big-tent project or neutron stadium project?
16:56:27 <trevormc> we can start here, if it consumes too much and not giving others time to talk, then we should move it to its own channel.
16:56:41 <Sukhdev> trevormc : +1
16:56:52 <rkukura> we are about out of time
16:57:08 <Sukhdev> rkukura : a new repo has been created, but is empty for now - I created it a week before summit
16:57:44 <Sukhdev> rkukura : the goal is that it will be part of neutron stadium - when fully done
16:57:45 <rkukura> Sukhdev: OK, lets cover this in a bit more detail next week
16:57:52 <Sukhdev> rkukura : sure
16:57:55 <rkukura> Anything else on the ML2 meeting format, etc.?
16:58:21 <rkukura> #topic Open Discussion
16:58:37 <yamamoto_> i want to announce one thing: i have a plan to do something dirty on ml2 tables https://review.openstack.org/#/c/464936/
16:59:27 <yamamoto_> ie. make midonet MD migrate some data from tables for midonet monolithic plugin to ml2
16:59:31 <Sukhdev> yamamoto_ : why is it dirty? :-)
16:59:58 <Sukhdev> yamamoto_ : oh I see - that is dirty -
17:00:34 <Sukhdev> yamamoto_ : you should not do it - why, what is the purpose
17:00:37 <yamamoto_> so i will be unhappy if ml2 schema changes come immediately before the next release. :-)
17:00:39 <rkukura> yamamoto_: Is this to ML2’s own tables, or to a midonet MD’s private tables?
17:00:51 <Sukhdev> yamamoto_ : when you are running monolithic plugin, why bother pushing things up?
17:00:57 <yamamoto_> ml2's own tables.  port binding etc
17:01:46 <rkukura> Is the goal for midonet to become an ML2 MD instead of a monolithic plugin?
17:01:47 <yamamoto_> we want to remove the monolithic plugin.  it's a part of a migration path for the users of the monolithic plugin.
17:02:08 <Sukhdev> yamamoto_ rkukura : we are past time - we should discuss this
17:02:10 <yamamoto_> rkukura: exactly. we already have ML2 MD.
17:02:12 <Sukhdev> next week
17:02:19 <rkukura> yamamoto_: lets continue this next week
17:02:25 <yamamoto_> sure
17:02:25 <rkukura> ok, time is up
17:02:28 <rkukura> thanks everyone!
17:02:29 <yamamoto_> thank you
17:02:34 <rkukura> #endmeeting