16:04:29 #startmeeting networking_ml2 16:04:30 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:04:33 The meeting name has been set to 'networking_ml2' 16:05:01 #link https://wiki.openstack.org/wiki/Meetings/ML2#Agenda 16:05:20 #topic Announcements 16:05:42 Looking forward to the summit next week 16:06:04 Anyone have any announcements? 16:06:44 I missed last week’s meeting, but have read the log. I don’t see any action items. 16:07:11 #topic Bugs 16:07:39 I still don’t see shivharis, our bug czar. 16:08:10 Does anyone know of any bugs needing discussion today? 16:08:30 https://bugs.launchpad.net/neutron/+bug/1179223 16:08:32 Launchpad bug 1179223 in neutron "Retired GRE and VXLAN tunnels persists in neutron db" [High,In progress] 16:09:05 romilg: Thanks. What is the current status on this? 16:09:09 Still need more reviewers 16:09:12 I have a couple of patches. one has one +2 and other has several +1's. 16:09:29 if someone could take a look and +2 (or suggest changes) that would be great. 16:09:34 https://review.openstack.org/124917 16:09:40 https://review.openstack.org/126360 16:09:59 One more, https://bugs.launchpad.net/neutron/+bug/1269131 16:10:06 Launchpad bug 1269131 in neutron "ML2 unit test coverage - db" [Low,In progress] 16:10:31 Need suggestion on patch set 16:10:55 manishg: I had started reviewing the first of those, will try to complete them. 16:10:58 https://review.openstack.org/130941 16:11:02 thank. 16:11:08 thx 16:11:47 Rectly started this bug for ML2 https://bugs.launchpad.net/neutron/+bug/1386059 16:11:49 Launchpad bug 1386059 in neutron "All LOG message should use gettextutils _LI, _LW, _LE, _LC" [Medium,In progress] 16:12:13 patch set for the same https://review.openstack.org/#/c/130992/6 16:13:06 manishg: I reviewed one of them - there were some comments and decided to wait until you addressed those 16:14:29 OK, these all seem to have good progress, and need review both within ML2 and by cores. 16:15:08 Are there any high or critical bugs that don’t have owners, or that owner’s are stuck on? 16:16:08 this one : https://bugs.launchpad.net/neutron/+bug/1361540 16:16:09 Launchpad bug 1361540 in neutron "no mechanism driver calls for gateway port removal" [High,In progress] 16:16:41 but I don't have any idea how to move forward... 16:17:23 Seems we need to eliminate direct DB changes that bypass the plugin. 16:18:52 +1 : you think I should code a call to ML2.delete_port even for port that should exist? 16:19:02 s/should/shouldn't 16:20:23 matrohon: If the port was created by the plugin, it must be deleted by the plugin. 16:21:27 rkukura: I think L3 Router service plugin creates the port, when it executes interface add to the router - 16:21:35 rkukura: not sure about the delete part 16:22:27 So, the question is should the delete port be invoked in the L3 Router service plugin 16:22:37 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 rkukura: agree 16:23:11 Is the race here that a new interface can get added while the router is being deleted? 16:23:24 rkukura : +1 16:23:39 rkukura: so, in that case both the creates and deletes should be through the ML2 plugin calls 16:23:40 rkukura : I think there is such races 16:24:16 that's the reason why mark did a last fixe to Juno, to cleanup stale ports 16:24:37 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 but he did it by invoking the db directly 16:25:38 do you think about a lock? 16:26:03 matrohon: Locks are local to a node. 16:26:32 so : db flag? 16:26:55 matrohon: That’s what I meant by “marks the router as ‘deleting’” 16:27:23 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 Lets continue this in the review, and at the summit. 16:28:27 rkukura : ok thanks. I'll think about it 16:29:08 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 Any other bugs to discuss? 16:29:25 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 absubram__: Thanks 16:30:42 #topic Specs for Kilo 16:31:06 https://blueprints.launchpad.net/python-neutronclient/+spec/neutron-cli-for-creating-multi-segment-network 16:31:49 lets review this and let me know...do we need this CLI or not :) 16:32:24 specs https://review.openstack.org/#/c/129575/ 16:32:38 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 romilg: Lets try to get him to look at your spec. 16:33:11 I have tht mail chain we didn't tht the proper CLI 16:33:13 romilg: I thought I can create multiple segments already via cli 16:33:37 pls let me know if it is already there 16:34:03 I'll take a look. I thought with multi-providernet this was taken care of. 16:34:04 with example I tried all possible combinations and left it 16:34:08 Clearly we need to either document how its done, or add the capability 16:34:50 So now is the time to be submitting specs for all kilo BPs for review. 16:35:07 yeah exactly :) 16:35:29 Do we want to continue to track these reviews in https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews? 16:35:36 rkukura romilg: I'll look at the spec. 16:35:54 mestery: thanks! 16:36:05 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 rkukura: when I started fixing one defect for mult-segment network I asked kyle as well as you 16:36:48 rkukura: i prefer something more mechanical than the wiki. eg. gerrit query recipe 16:37:09 mystery: with this command I believe we should be able to create multiple segments from cli. right? 16:37:27 romilg: manishg may have the incantation! 16:37:29 I will test this cmd and post it 16:37:46 manishg: i vaguely remember i needed to read client code to figure out how to do it. we need doc improvement. 16:37:54 Thanks Manish :) 16:38:09 yamamoto: agree. I had to fiure this from code. no docs I believe. 16:38:48 OK, lets at least document how this is done with the current CLI. 16:39:39 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 I think its important the the ML2 subteam members do initial reviews on the ML2-related specs. 16:41:44 rkukura: +1 16:41:54 I agree maintaining a wiki for the reviews is cumbersome and its ofter out-of-date. 16:42:28 rkukura: sure. at least the list of specs needs to be maintained by human beings. 16:43:09 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 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 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 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 yamamoto: that would be nice! 16:44:29 yamamoto: that would be great! 16:44:44 OK, lets move on 16:44:53 #topic Kilo Design Summit 16:45:24 I’m thinking we’ll skip the IRC meeting next week due to the summit. 16:46:08 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 there will be plenty of etherpads and such for updates to everyone! 16:46:26 We’ll have the oportunity to discuss ML2-related topics both in sessions and in the Pod. 16:46:36 rkukura: yes - no meeting next week 16:47:14 The design sessions are: https://etherpad.openstack.org/p/kilo-neutron-summit-topics-distilled 16:47:50 Day 1, item 2 is clearly relevant to ML2! 16:49:18 Does anyone want to discuss any of the summit design session topics here briefly? 16:49:24 link: http://kilodesignsummit.sched.org/overview/type/neutron#.VFEafNR4p49 - here is official schedule 16:49:45 Sukhdev: Thanks! 16:50:18 I expect we will want to have a Pod discussion of TaskFlow / error recovery if possible 16:50:27 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 and do the real discussions in the PODs as well round table meetings (on the last day) 16:50:47 rkukura, I've been working on the taskflow integration. and there are many open questions. 16:51:03 some of which you had brought up also. and it would be good to discuss them next week. 16:51:16 manishg: agreed 16:51:26 manishg: +1 - lets discuss those for sure 16:51:41 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 Do we need a POD session on hierarchical port binding? I’ll have that spec updated and in review. 16:52:18 Or a POD session on next steps for extension drivers? 16:52:30 Or on agent modularization? 16:52:52 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 manishg: Thanks! 16:53:11 rkukura: I think agent modularization would be a good topic. 16:53:23 but I think banix isn't able to attend the summit, right? 16:54:25 regd modular L2 agent, anything updated after https://review.openstack.org/#/c/106189/2/specs/juno/modular-l2-agent.rst? 16:54:26 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 Sukhdev: makes sense, but might be difficult to schedule 16:54:58 rkukura: depending upon the interest level, folks can come and join in the disucssion 16:55:11 Any other suggestions for POD sessions of wide interest in ML2? 16:55:38 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 rkukura: +1 for pod sessions for hierarchical port binding 16:55:56 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 rkukura: hierarchical port-binding session, yes. 16:56:38 as well as extension drivers. +1. 16:56:41 #action: rkukura and Sukhdev to organize POD sessions for these 16:56:51 Any others? 16:57:19 #topic Open Discussion 16:57:47 rkukura: I think we should ask for a slot in the round table discussion for ML2 Sync/TaskFlow discussion as well 16:58:22 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 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 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 Sukhdev: sounds good 16:59:20 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 manishg: Supporting heterogeneous deployments was one of the original goals for ML2. 16:59:53 manishg: why do you ask? there is a use case for ovs+vm-fex mech driver+nexus mech driver 17:00:02 OK, thanks everybody! Looking forward to seeing many of you next week! 17:00:06 rkukura: understood. but I was curious how people use it today. 17:00:29 nexus or any other upstream switch mech driver 17:00:36 manishg: Lets followup on that at the summit or the week after. 17:00:39 #endmeeting