16:01:28 <Sukhdev> #startmeeting networking_ml2
16:01:29 <openstack> Meeting started Wed Jun  1 16:01:28 2016 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:32 <openstack> The meeting name has been set to 'networking_ml2'
16:01:41 <Sukhdev> #topic: Agenda
16:01:48 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_June_1.2C_2016
16:02:05 <Sukhdev> #topic: Announcements
16:02:40 <Sukhdev> N-1 is this week
16:02:50 <Sukhdev> #link - http://releases.openstack.org/newton/schedule.html
16:03:02 <Sukhdev> time flies :-)
16:03:28 <Sukhdev> I forgot to ask - does anybody want to add anything to the agenda?
16:03:58 <Sukhdev> Anybody has any announcements?
16:04:05 <rkukura> neither from me
16:04:16 <Sukhdev> Warriors won Western Finals - Yay!!!!
16:05:05 <Sukhdev> enough celebration - moving along -
16:05:17 <Sukhdev> #topic: Manila Integration
16:05:41 <Sukhdev> We discussed at the Austin Summit about Manila/ML2 integration
16:05:50 <Sukhdev> I filed the RFE for it -
16:06:11 <Sukhdev> #link: https://bugs.launchpad.net/neutron/+bug/1573197
16:06:11 <openstack> Launchpad bug 1573197 in neutron "[RFE] Neutron API enhancement for visibility into multi-segmented networks" [Undecided,Triaged]
16:06:36 <Sukhdev> This is the next item on my mind to pick up
16:06:50 <Sukhdev> anybody has any interest on working on it?
16:07:35 <Sukhdev> Silence is golden, but, in this case, it is not :-):-)
16:07:51 <rkukura> interest, but probably not time
16:08:23 <Sukhdev> rkukura : understood - perhaps we will use you as a consultant in that case
16:08:40 <rkukura> I’m still a little uneasy with the idea of manila “passively” participating in port binding
16:09:15 <Sukhdev> rkukura : No, we would not want them to do that -
16:10:05 <Sukhdev> rkukura : with the implementation that I am thinking - we want to provide a way for ML2 driver (any driver) to have the ability to export (or present) the binding information
16:10:16 <rkukura> At least with HPB, it seems like a manila mechanism driver should be involved by doing the actual set_binding() call. If it does this, it would know which segment is being bound, and could use that info to configure the file server.
16:11:06 <rkukura> But I still do agree that exposing the binding outcome through the API is desirable, at least for admin purposes
16:11:31 <Sukhdev> rkukura: so, there are two parts to this puzzle -
16:11:32 <rkukura> So I fully support implementing the RFE
16:11:50 <Sukhdev> 1) as you mention - visibility for the admins
16:12:17 <Sukhdev> 2) the ability to provision the seg-id in the file system
16:12:53 <Sukhdev> for 2, yes, we would need a manila specific of manila supporting ML2 - as we do in case of Ironic
16:13:04 <Sukhdev> s/of/or
16:13:58 <Sukhdev> In the coming weeks, we will kick of the work in this RFE, then we can discuss more details here
16:14:31 <Sukhdev> Anybody has any input/feedback on this?
16:14:47 <Sukhdev> other than what rkukura already mentioned
16:15:29 <Sukhdev> moving right along -
16:15:46 <Sukhdev> #topic: Security Group Discussion
16:16:04 <Sukhdev> I have been working on the implementation of SGs for past weeks
16:16:44 <Sukhdev> I noticed we had couple of specs for the SG APIs - by yamamoto
16:17:21 <Sukhdev> yamamoto : I wanted to understand the issues that you faced in this regard
16:18:12 <yamamoto> couple of specs?  i don't remember :-)
16:18:43 <rkukura> Sukhdev: Are you refering to adding precommit and postcommit calls on MDs for SG operations?
16:18:58 <Sukhdev> rkukura : yes
16:19:18 <yamamoto> we suffered from the lack of SG ops in ml2.  pre/postcommit would help.  we currently using callbacks.
16:19:38 <rkukura> As I recall, the resistance was based on the idea that the notification mechanism could be used instead, but it does not seem to be fully implemented either
16:20:04 <rkukura> And there are cases where we would want to raise exceptions in precommit for SG rules that cannot be enforced by the bound MD
16:20:45 <Sukhdev> right -
16:20:47 <rkukura> The notifications I was referring to are the same callbacks yamamoto mentioned, I think
16:20:58 <yamamoto> yes, same
16:21:36 <Sukhdev> so, I wanted to provide some feedback based upon my exeperiance working with SGs
16:21:44 <yamamoto> odl folks added precommit notifications while ago.  i don't know if it's complete (for their purpose) though.
16:21:59 <Sukhdev> So, there are two types of notifications -
16:22:18 <Sukhdev> i.e. you can register for Before and After
16:22:43 <Sukhdev> i.e. before the SG is applied (or created) as the case may be
16:22:57 <rkukura> so before is during the transaction, and can roll it back by raising an exception?
16:22:58 <Sukhdev> and after - i.e after SG is created, etc
16:23:16 <Sukhdev> rkukura : correct
16:23:45 <yamamoto> before is usually before transaction begins.
16:23:58 <yamamoto> precommit is during transaction
16:24:06 <yamamoto> after is after transaction
16:24:07 <Sukhdev> however there is no current and previous context - as is in the update operation in ML2
16:24:23 <rkukura> Sukhdev: was going to mention that next
16:25:23 <Sukhdev> So, I was able to achieve what I wanted to - with this framework
16:25:49 <Sukhdev> but, had a nagging feeling that I may be missing something - hence, the purpose of this discussion
16:26:07 <yamamoto> notifcation arguments are somewhat ad-hoc.  some of them might have enough context, others might not.  i personally prefer uniform way like ml2 pre/postcommit methods.
16:26:09 <Sukhdev> just to learn from the experts who have gone through this path before
16:27:02 <Sukhdev> yamamoto : correct - especially in the security-group-update
16:27:16 <rkukura> My view is that ML2 should treat all resources it implements consistently, supporting MD and ED calls. This includes SGs, QoS, SubnetPools, AddressScopes, …
16:27:52 <yamamoto> rkukura: i agree
16:29:35 <Sukhdev> in the present implementation, since two contexts are not available, I was able to pull them from the DB by using before and after notifications
16:29:41 <Sukhdev> to achieve my goal
16:30:37 <rkukura> Sukhdev: If we did implemement the precommit/postcommit/Context pattern for SG resources, would you prefer to use that instead?
16:31:49 <Sukhdev> At this point, since, I got it working, I am probably OK - however, if I had it available to me, I would have preferred that
16:32:09 <Sukhdev> because it takes the guesswork out and makes the interface look uniform
16:33:28 <Sukhdev> Thanks for your insight into this yamamoto and rkukura
16:33:38 <Sukhdev> moving right along -
16:33:47 <Sukhdev> #topic Open Discussion
16:33:59 <carl_baldwin> I had a couple of things.
16:34:08 <Sukhdev> there are two topics for this one on the agenda and other one I would like to bring up
16:34:31 <Sukhdev> carl_baldwin : yes, you go first - as you are on the agenda
16:34:47 <carl_baldwin> The first is that Hong Hui Xiao is working on create / delete segments on existing network.
16:34:49 <carl_baldwin> #link
16:34:56 <carl_baldwin> oops
16:35:00 <carl_baldwin> #link https://review.openstack.org/#/c/317358
16:35:30 <carl_baldwin> We started an ML thread about it.
16:35:32 <carl_baldwin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/094833.html
16:35:42 <Sukhdev> carl_baldwin : I started to review it this morning - have not finished it yet
16:35:53 <carl_baldwin> Basically, I'll feel much more comfortable with his implementation with some of your skilled eyes on the code.
16:36:01 <carl_baldwin> Sukhdev: Thank you for that.
16:36:28 <carl_baldwin> The second thing is a bug that is also being worked on by the same contributor (IRC:  xiaohhui)
16:36:40 <carl_baldwin> #link https://review.openstack.org/#/c/321152
16:37:09 <carl_baldwin> Basically, we will defer an IP allocation until after Nova does scheduling.
16:37:20 <carl_baldwin> Then Nova will do a port update which will allocate the IP address.
16:37:45 <carl_baldwin> The IP address gets allocated, but is not returned in the response.  So, Nova would have to make a follow-up GET call to see the IPs allocated.
16:38:24 <carl_baldwin> xiaohhui sent an email to the ML because he is perplexed.
16:38:26 <carl_baldwin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/096036.html
16:38:54 <rkukura> carl_baldwin: I should posted a review comment on this - the get_port() and call to the base class need to be part of the transaction
16:39:02 <carl_baldwin> It would be great to have some guidance on how to fix this properly.
16:39:34 <carl_baldwin> rkukura:  That would be great if you could review.
16:40:02 <carl_baldwin> That's all I have.  Thank you very much for your time.
16:40:16 <rkukura> carl_baldwin: I meant to say “I just posted …”, not “I should post …”, but I will continue to review it
16:40:32 <carl_baldwin> rkukura: Ah, I must not have seen it yet.  Thanks.
16:40:50 <carl_baldwin> I see it now.
16:41:03 <rkukura> Just, and in 1 minute ago ;)
16:41:12 <rkukura> I can’t type today
16:41:19 <rkukura> Just, as in ...
16:41:54 <carl_baldwin> lol
16:42:45 <carl_baldwin> If you could take a look at his ML post too, that would be great.  I haven't been able to wrap my head around it yet.
16:43:06 <rkukura> carl_baldwin: I will look for it
16:43:19 <Sukhdev> carl_baldwin: I will go through all of this later today
16:43:27 <carl_baldwin> rkukura: See link to ML post above.
16:44:16 <Sukhdev> anything else?
16:44:41 <Sukhdev> If we are done with this topic, I have one topic to bring up
16:45:05 <Sukhdev> I would like to discuss the frequency of this meeting -
16:45:26 <carl_baldwin> done
16:45:41 <Sukhdev> carl_baldwin : thanks
16:46:07 <Sukhdev> So, shall we keep the frequency of this meeting weekly, or should we slow it down a bit - i.e. every other week?
16:46:20 <Sukhdev> I would like to open the floor for discussion on this
16:47:42 <rkukura> If we are continuing to actively develop ML2, I think weekly is justified. But if we are not, maybe less often.
16:48:42 <Sukhdev> We have couple of work items that are going on in neutron -
16:49:07 <Sukhdev> one by carl_baldwin and his team for routed networks, which we should be paying attention to
16:49:18 <Sukhdev> and the other RFE that I mentioned earlier
16:49:37 <Sukhdev> both of these impact ML2 in a reasonable way
16:49:51 <rkukura> Yes, and I’d also like to continue today’s discussion on completing ML2’s driver API for other resources
16:50:31 <Sukhdev> rkukura : do you intend to file RFE for the ML2 driver API?
16:50:55 <rkukura> Sukhdev: I had mentioned that I did plan to, so I should
16:51:14 <rkukura> I’ll try to do that by next meeting
16:51:29 <Sukhdev> So, this makes it three work items -
16:51:51 <Sukhdev> in that case, we can continue to meet weekly and not change the frequency
16:51:59 <rkukura> Sounds like “actively developing” to me
16:52:35 <Sukhdev> I just wanted to throw it out there - to see how folks feel
16:53:11 <yamamoto> i suspect stadium evolution thing might make some plugins move to ml2, and expose some more shortage in driver api.
16:53:41 <rkukura> yamamoto: good point
16:54:00 <yamamoto> like this https://bugs.launchpad.net/neutron/+bug/1587401
16:54:00 <openstack> Launchpad bug 1587401 in neutron "Helper method to change status of port to abnormal state is needed in ml2." [Undecided,New]
16:55:31 <Sukhdev> yamamoto: we used to track ML2 related bugs in this meeting, but, over time we have stopped doing it
16:55:38 <rkukura> maybe we should use these meetings to triage new bugs tagged with ml2
16:56:21 <Sukhdev> ever since shivharris is gone, we have stopped tracking the bug :-(
16:56:42 <rkukura> we had been tracking them until they closed, which wasn’t all that helpful, but maybe some sort of triage of new bugs, would be worthwhile
16:56:46 <yamamoto> given that we have enough topic to keep discussing for ~55 min today, i guess the current frequency is appropriate. :-)
16:57:20 <Sukhdev> yamamoto : point well made
16:57:58 <Sukhdev> so, we are good with the frequency
16:58:37 <Sukhdev> rkukura : perhaps we should start listing ML2 tagged bugs on our weekly agenda so that we can triage those here
16:58:55 <rkukura> Sukhdev: at least the new ones
16:59:09 <Sukhdev> yup
16:59:16 * Sukhdev time check 1 min left
16:59:28 <Sukhdev> Anything else?
16:59:35 <Sukhdev> we are almost out of time
16:59:56 <yamamoto> nothing from me
17:00:14 <Sukhdev> our time is up - thanks everybody for attending
17:00:19 <yamamoto> thank you
17:00:21 <Sukhdev> have a wonderful day
17:00:28 <Sukhdev> bye
17:00:28 <yamamoto> good night
17:00:31 <Sukhdev> #endmeeting