16:04:29 <rkukura> #startmeeting networking_ml2
16:04:30 <openstack> Meeting started Wed Oct 29 16:04:29 2014 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:33 <openstack> The meeting name has been set to 'networking_ml2'
16:05:01 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Agenda
16:05:20 <rkukura> #topic Announcements
16:05:42 <rkukura> Looking forward to the summit next week
16:06:04 <rkukura> Anyone have any announcements?
16:06:44 <rkukura> I missed last week’s meeting, but have read the log. I don’t see any action items.
16:07:11 <rkukura> #topic Bugs
16:07:39 <rkukura> I still don’t see shivharis, our bug czar.
16:08:10 <rkukura> Does anyone know of any bugs needing discussion today?
16:08:30 <romilg> https://bugs.launchpad.net/neutron/+bug/1179223
16:08:32 <uvirtbot> Launchpad bug 1179223 in neutron "Retired GRE and VXLAN tunnels persists in neutron db" [High,In progress]
16:09:05 <rkukura> romilg: Thanks. What is the current status on this?
16:09:09 <romilg> Still need more reviewers
16:09:12 <manishg> I have a couple of patches.  one has one +2 and other has several +1's.
16:09:29 <manishg> if someone could take a look and +2 (or suggest changes) that would be great.
16:09:34 <manishg> https://review.openstack.org/124917
16:09:40 <manishg> https://review.openstack.org/126360
16:09:59 <romilg> One more, https://bugs.launchpad.net/neutron/+bug/1269131
16:10:06 <uvirtbot> Launchpad bug 1269131 in neutron "ML2 unit test coverage - db" [Low,In progress]
16:10:31 <romilg> Need suggestion on patch set
16:10:55 <rkukura> manishg: I had started reviewing the first of those, will try to complete them.
16:10:58 <romilg> https://review.openstack.org/130941
16:11:02 <manishg> thank.
16:11:08 <manishg> thx
16:11:47 <romilg> Rectly started this bug for ML2 https://bugs.launchpad.net/neutron/+bug/1386059
16:11:49 <uvirtbot> Launchpad bug 1386059 in neutron "All LOG message should use gettextutils _LI, _LW, _LE, _LC" [Medium,In progress]
16:12:13 <romilg> patch set for the same https://review.openstack.org/#/c/130992/6
16:13:06 <Sukhdev> manishg: I reviewed one of them - there were some comments and decided to wait until you addressed those
16:14:29 <rkukura> OK, these all seem to have good progress, and need review both within ML2 and by cores.
16:15:08 <rkukura> Are there any high or critical bugs that don’t have owners, or that owner’s are stuck on?
16:16:08 <matrohon> this one : https://bugs.launchpad.net/neutron/+bug/1361540
16:16:09 <uvirtbot> Launchpad bug 1361540 in neutron "no mechanism driver calls for gateway port removal" [High,In progress]
16:16:41 <matrohon> but I don't have any idea how to move forward...
16:17:23 <rkukura> Seems we need to eliminate direct DB changes that bypass the plugin.
16:18:52 <matrohon> +1 : you think I should code a call to ML2.delete_port even for port that should exist?
16:19:02 <matrohon> s/should/shouldn't
16:20:23 <rkukura> matrohon: If the port was created by the plugin, it must be deleted by the plugin.
16:21:27 <Sukhdev> rkukura: I think L3 Router service plugin creates the port, when it executes interface add to the router -
16:21:35 <Sukhdev> rkukura: not sure about the delete part
16:22:27 <Sukhdev> So, the question is should the delete port be invoked in the L3 Router service plugin
16:22:37 <rkukura> matrohon, Sukhdev: I have not looked closely enough at the patch in review, but in general, I feel pretty strongly that no code should be going around the plugin and manipulating the DB directly, ever.
16:23:08 <Sukhdev> rkukura: agree
16:23:11 <rkukura> Is the race here that a new interface can get added while the router is being deleted?
16:23:24 <matrohon> rkukura : +1
16:23:39 <Sukhdev> rkukura: so, in that case both the creates and deletes should be through the ML2 plugin calls
16:23:40 <matrohon> rkukura : I think there is such races
16:24:16 <matrohon> that's the reason why mark did a last fixe to Juno, to cleanup stale ports
16:24:37 <rkukura> Then it seems we either need an initial transaction that marks the router as “deleting” and prevents and interfaces from being added, or we need a loop that retries the entire tranaction if any interfaces get added.
16:24:43 <matrohon> but he did it by invoking the db directly
16:25:38 <matrohon> do you think about a lock?
16:26:03 <rkukura> matrohon: Locks are local to a node.
16:26:32 <matrohon> so : db flag?
16:26:55 <rkukura> matrohon: That’s what I meant by “marks the router as ‘deleting’”
16:27:23 <manishg> rkukura: I haven't looked at the patch in question but introducing state like what you are suggesting seems like a good idea to avoid some of these races.
16:28:25 <rkukura> Lets continue this in the review, and at the summit.
16:28:27 <matrohon> rkukura : ok thanks. I'll think about it
16:29:08 <rkukura> we do need a consistent approach to dealing with these sorts of race conditions. Same thing with adding ports to networks and subnets, etc..
16:29:22 <rkukura> Any other bugs to discuss?
16:29:25 <absubram__> I have a low priority one that I brought up last week.. I sent out a new version and it has one +2.. needs a second please.. https://review.openstack.org/#/c/105514/
16:30:24 <rkukura> absubram__: Thanks
16:30:42 <rkukura> #topic Specs for Kilo
16:31:06 <romilg> https://blueprints.launchpad.net/python-neutronclient/+spec/neutron-cli-for-creating-multi-segment-network
16:31:49 <romilg> lets review this and let me know...do we need this CLI or not :)
16:32:24 <romilg> specs https://review.openstack.org/#/c/129575/
16:32:38 <rkukura> romilg: I recall that mestery had figured out some way to do this with the CLI back when when he implemented the multiprovidernet extension for ML2
16:32:56 <rkukura> romilg: Lets try to get him to look at your spec.
16:33:11 <romilg> I have tht mail chain we didn't tht the proper CLI
16:33:13 <manishg> romilg: I thought I can create multiple segments already via cli
16:33:37 <romilg> pls let me know if it is already there
16:34:03 <manishg> I'll take a look.  I thought with multi-providernet this was taken care of.
16:34:04 <romilg> with example I tried all possible combinations and left it
16:34:08 <rkukura> Clearly we need to either document how its done, or add the capability
16:34:50 <rkukura> So now is the time to be submitting specs for all kilo BPs for review.
16:35:07 <romilg> yeah exactly :)
16:35:29 <rkukura> Do we want to continue to track these reviews in https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews?
16:35:36 <mestery> rkukura romilg: I'll look at the spec.
16:35:54 <rkukura> mestery: thanks!
16:36:05 <manishg> romilg: neutron net-create multinet --segments type=dict list=true provider:physical_network=blah,provider:segmentation_id=blah, provider:network_type=vlan
16:36:12 <romilg> rkukura: when I started fixing one defect for mult-segment network I asked kyle as well as you
16:36:48 <yamamoto> rkukura: i prefer something more mechanical than the wiki.  eg. gerrit query recipe
16:37:09 <manishg> mystery: with this command I believe we should be able to create multiple segments from cli.  right?
16:37:27 <rkukura> romilg: manishg may have the incantation!
16:37:29 <romilg> I will test this cmd and post it
16:37:46 <yamamoto> manishg: i vaguely remember i needed to read client code to figure out how to do it.  we need doc improvement.
16:37:54 <romilg> Thanks Manish :)
16:38:09 <manishg> yamamoto: agree.  I had to fiure this from code.  no docs I believe.
16:38:48 <rkukura> OK, lets at least document how this is done with the current CLI.
16:39:39 <rkukura> yamamoto: I guess the real question is how can we best use some time in these meetings to ensure the ML2 spec reviews are progressing?
16:41:06 <rkukura> I think its important the the ML2 subteam members do initial reviews on the ML2-related specs.
16:41:44 <manishg> rkukura: +1
16:41:54 <rkukura> I agree maintaining a wiki for the reviews is cumbersome and its ofter out-of-date.
16:42:28 <yamamoto> rkukura: sure.  at least the list of specs needs to be maintained by human beings.
16:43:09 <rkukura> Should we put a discussion on the sub-team’s spec review process on the agenda for the week after the summit?
16:44:00 <yamamoto> it has been on my todo list to write a script which takes the list of specs and produces the wiki equivalent..
16:44:05 <rkukura> I’m not sure if there is a deadline for submitting specs for Kilo, but we should try to get these all in within the next couple weeks.
16:44:06 <manishg> I think it's good to review the list from time to time also.  to make sure they are getting attention and progressing.  + add any new ones (this doesn't change as often I guess)
16:44:19 <rkukura> yamamoto: that would be nice!
16:44:29 <manishg> yamamoto: that would be great!
16:44:44 <rkukura> OK, lets move on
16:44:53 <rkukura> #topic Kilo Design Summit
16:45:24 <rkukura> I’m thinking we’ll skip the IRC meeting next week due to the summit.
16:46:08 <manishg> rkukura: I think there won't be any other meetings next week due to summit - folks will be busy at the summit.  so I'd vote for skipping it next week.
16:46:25 <manishg> there will be plenty of etherpads and such for updates to everyone!
16:46:26 <rkukura> We’ll have the oportunity to discuss ML2-related topics both in sessions and in the Pod.
16:46:36 <Sukhdev> rkukura: yes - no meeting next week
16:47:14 <rkukura> The design sessions are: https://etherpad.openstack.org/p/kilo-neutron-summit-topics-distilled
16:47:50 <rkukura> Day 1, item 2 is clearly relevant to ML2!
16:49:18 <rkukura> Does anyone want to discuss any of the summit design session topics here briefly?
16:49:24 <Sukhdev> link: http://kilodesignsummit.sched.org/overview/type/neutron#.VFEafNR4p49 - here is official schedule
16:49:45 <rkukura> Sukhdev: Thanks!
16:50:18 <rkukura> I expect we will want to have a Pod discussion of TaskFlow / error recovery if possible
16:50:27 <Sukhdev> Since we do not have a formal slot in the main session - my thought was we use part of the session to make announcements for our PODs discussions
16:50:46 <Sukhdev> and do the real discussions in the PODs as well round table meetings (on the last day)
16:50:47 <manishg> rkukura, I've been working on the taskflow integration.  and there are many open questions.
16:51:03 <manishg> some of which you had brought up also.  and it would be good to discuss them next week.
16:51:16 <rkukura> manishg: agreed
16:51:26 <Sukhdev> manishg: +1 - lets discuss those for sure
16:51:41 <manishg> I have some code that I'll try to upload so folks can look at it.  after that I'll send the doc too.
16:51:45 <rkukura> Do we need a POD session on hierarchical port binding? I’ll have that spec updated and in review.
16:52:18 <rkukura> Or a POD session on next steps for extension drivers?
16:52:30 <rkukura> Or on agent modularization?
16:52:52 <manishg> this will I"ll try to populate the doc here: https://docs.google.com/document/d/1SDr3NEL7wjOfMvQ3GrCLbgjLhhLrMzNcaG2DIRNPV4Y/edit?usp=sharing -- for those interested in taskflow/ ML2 integration.  the doc is blank now - will add stuff later this week.
16:53:08 <rkukura> manishg: Thanks!
16:53:11 <manishg> rkukura: I think agent modularization would be a good topic.
16:53:23 <manishg> but I think banix isn't able to attend the summit, right?
16:54:25 <padkrish> regd modular L2 agent, anything updated after https://review.openstack.org/#/c/106189/2/specs/juno/modular-l2-agent.rst?
16:54:26 <Sukhdev> rkukura: It depends upon the participants - my suggestion is we pick time slots for each of these topics and announce it in the main session
16:54:52 <rkukura> Sukhdev: makes sense, but might be difficult to schedule
16:54:58 <Sukhdev> rkukura: depending upon the interest level, folks can come and join in the disucssion
16:55:11 <rkukura> Any other suggestions for POD sessions of wide interest in ML2?
16:55:38 <Sukhdev> rkukura: My thought is we pick in the order of priority and pick times which are not in conflict with Neutron Sessions
16:55:42 <sadasu> rkukura: +1 for pod sessions for hierarchical port binding
16:55:56 <manishg> rkukura, Sukhdev: it would also be good to have quick 'info sessions' in the pod area where people can introduce the specs - maybe not have full discussions (this could be short).  this could be informal.
16:56:13 <manishg> rkukura: hierarchical port-binding session, yes.
16:56:38 <manishg> as well as extension drivers. +1.
16:56:41 <rkukura> #action: rkukura and Sukhdev to organize POD sessions for these
16:56:51 <rkukura> Any others?
16:57:19 <rkukura> #topic Open Discussion
16:57:47 <Sukhdev> rkukura: I think we should ask for a slot in the round table discussion for ML2 Sync/TaskFlow discussion as well
16:58:22 <rkukura> Sukhdev: Are those being scheduled ahead of time, or will that be done based on what we need after the design sessions?
16:58:33 <Sukhdev> Round Table takes place on Friday - by then we would have hashed out some of the taskflow related issues - this will be an opportunity to discuss with wider audience
16:58:41 <manishg> are there any use cases for multiple mech-drivers (not including agent-based mech drivers)?  or are most of the cases where we use ovs/linuxbridge + one of the other mech drivers?
16:58:43 <rkukura> Sukhdev: sounds good
16:59:20 <manishg> Sukhdev: +1.  would be certainly a good idea to discuss with wider audience.  And before Friday we'd have had plenty of time to hash the issues out.
16:59:32 <rkukura> manishg: Supporting heterogeneous deployments was one of the original goals for ML2.
16:59:53 <sadasu> manishg: why do you ask? there is a use case for ovs+vm-fex mech driver+nexus mech driver
17:00:02 <rkukura> OK, thanks everybody! Looking forward to seeing many of you next week!
17:00:06 <manishg> rkukura: understood.  but I was curious how people use it today.
17:00:29 <sadasu> nexus or any other upstream switch mech driver
17:00:36 <rkukura> manishg: Lets followup on that at the summit or the week after.
17:00:39 <rkukura> #endmeeting