16:02:46 #startmeeting networking_ml2 16:02:47 Meeting started Wed Oct 8 16:02:46 2014 UTC and is due to finish in 60 minutes. The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:50 The meeting name has been set to 'networking_ml2' 16:03:09 #topic: Agenda 16:03:27 #link: https://wiki.openstack.org/wiki/Meetings/ML2#Agenda 16:03:45 #topic: Announcements 16:04:18 #info: Juno-RC1 is cut 16:04:36 #link: https://launchpad.net/neutron/+milestone/juno-rc1 16:05:01 The release notes are here - https://wiki.openstack.org/wiki/ReleaseNotes/Juno#OpenStack_Network_Service_.28Neutron.29 16:05:15 #info: RC2 is being planned 16:05:51 So, if you have any critical item that needs to be included in Juno, please tag it with juno-rc-potential 16:06:46 A Neutron Driver team is formed to manage the Neutron drivers better 16:07:05 you can find information here - https://wiki.openstack.org/wiki/Neutron-drivers 16:07:27 Sukhdev: don’t you mean “manage the Neutron specs better”? 16:07:44 yes - thanks for correcting 16:07:52 Sukhdev, manage drivers or direction in general? 16:08:06 k. 16:08:07 Spec approval team 16:08:36 With powers of A+. 16:08:37 manage specs and make sure they overall align well within the Neutron architecture 16:09:09 maintaining the integrity of the Neutron architecture - I guess 16:09:18 Is anyone else concerned that, with Kyle not involved in ML2 lately, ML2 is not adequately represented in this group? 16:10:41 rkukura: good point 16:11:17 rkukura: I thought he was over-burdened with other PTL activities 16:11:21 rkukura, you mean the ML2 subgroup not represented in the larger neutron group? 16:11:54 so is there going to be a rep from each subgroup? dvr, ml2, ipv6 , etc 16:12:00 amotoki does participate in ML2 prettyy regularly, so he may be our neutron-drivers go-to person for now 16:12:26 rkukura +1 16:12:48 I don’t think the idea is to have reps from each group, but I think coordinating ML2 and the overall neutron architectural direction is extremely critical 16:13:25 But mestery its also active for ML2 16:14:44 rkukura: amotoki is fairly active here as well as in Neutron - so, lets see how it plays out. 16:15:02 rkukura: thanks. makes sense. as long as the folks in drivers team are aware of ml2 direction it should work. 16:15:10 rkukura: if we see an issue or a bottleneck, we can raise the red flag 16:15:31 does amotoki know we are depending on him? 16:16:17 shivharis: I hope so….I wish he was here today to answer that question :-) 16:16:39 amotoki just quit... Lawyer ... Where are you.. 16:16:39 Any other announcements? 16:17:08 Shall we move on? 16:17:33 There were no action items from last week as far as I can tell 16:17:44 #topic Bugs: 16:17:52 shivharis: want to cover? 16:17:54 hi 16:18:15 I will be very quick today, need the time for discussion of summit topics 16:18:36 I have a few questions about bugs. should I hold them till open discussion? 16:18:39 only extremely critical bugs will now get into Juno 16:19:00 manishg__: please go ahead.. 16:19:14 I fixed two ml2 bugs - would be great if someone can review. 16:19:21 bug: https://bugs.launchpad.net/neutron/+bug/1325664 . 16:19:22 Launchpad bug 1325664 in neutron "ML2: validate network configuration" [Low,In progress] 16:19:26 patch here - https://review.openstack.org/126360 16:19:33 bug: https://bugs.launchpad.net/neutron/+bug/1333475 16:19:37 Launchpad bug 1333475 in neutron "ML2 : network filters for provider attributes not implemented " [Low,In progress] 16:19:39 patch here - https://review.openstack.org/124917 16:19:47 Also , This bugs requires refactoring parts of ovs agent but 16:19:53 I think we want to avoid that effort 16:19:59 till modular L2 effort lead by banix is done, right? 16:20:04 here's the bug - https://bugs.launchpad.net/neutron/+bug/1264608 16:20:05 Launchpad bug 1264608 in neutron "openvswitch agent plugin should execute batched ovs-vsctl CLI statements on __init__()" [Medium,Triaged] 16:20:24 manishg__: correct 16:20:31 accepted. Thanks we will solicit this from the entire team shortly, i will keep this on the list for tracking. 16:20:42 I also ran into this test code which I didn't look right 16:20:47 so filed a bug - https://bugs.launchpad.net/neutron/+bug/1377346 16:20:48 Launchpad bug 1377346 in neutron "ML2: Invalid unit test case" [Undecided,New] 16:20:55 so if someone can triage it that would be great. 16:21:09 shivharis: thanks. 16:21:11 manishg__: I will look at them later today 16:21:19 Other bugs that show up under ML2 are either assigned to others or are blocked on some blueprint. Anything that I missed there that is open? 16:21:57 manishg__: any other comments? 16:22:02 https://bugs.launchpad.net/neutron/+bug/1377346 16:22:04 Launchpad bug 1377346 in neutron "ML2: Invalid unit test case" [Undecided,New] 16:22:11 shivharis: no thanks. that's it. 16:22:13 i fixed that 16:22:45 as part of https://bugs.launchpad.net/neutron/+bug/1224978 16:22:49 romilg: in review? 16:22:50 Launchpad bug 1224978 in neutron "port binding on multi segment networks could lead to agent misconfiguration" [Medium,In progress] 16:22:56 romilg: thanks. 16:23:35 Ok, back to the agenda. 16:23:53 romilg: patch? 16:24:00 We have a few bugs that need to get a milestone target 16:24:18 rkukura; can you please help on that 16:24:34 shivharis: I’ll try 16:25:07 shivharis: what do you mean by milestone target? 16:25:27 I am hoping the target for all these are k1 16:25:32 (or k2) 16:25:45 this need to be set 16:25:50 Oh I see 16:26:07 looks like k2 doesn’t exist yet, so I’ll set them to k1 16:26:44 chuckc, kevinbenton: can you please close the bugs that you have in progress - appears everything has been done 16:27:22 I will get manishg__ and romilg's bugs/patches on the list next time 16:27:32 thats all i have, lets move on 16:27:43 shivharis: thanks 16:28:17 #link https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews#Under_Review 16:28:47 I have kept this link in the agenda so that people can refer to what specs and code reviews are out there 16:28:59 #topic: Kilo planning 16:29:44 Here is etherpad for Kilo design summit consideration - https://etherpad.openstack.org/p/kilo-neutron-summit-topics 16:30:10 rkukura took an effort to come up with a list of ML2 specific items 16:30:33 I think it is important to separte kilo planning from summit planning 16:30:40 These items are listed in the agenda https://wiki.openstack.org/wiki/Meetings/ML2#Agenda 16:30:41 s/separte/separate/ 16:31:03 rkukura: correct 16:31:13 we need to figure out what we plan to accomplish in ML2 during kilo, then figure out what we need to do at the summit to enable that 16:31:35 not all important items necessarily need time at the summit 16:31:56 Shall we go item-by-item from the list and see the interest level? 16:32:56 Sukhdev: +1 16:33:09 Cleanup/generalize DVR's distributed port support 16:33:30 #link: https://bugs.launchpad.net/neutron/+bug/1367391 16:33:31 Launchpad bug 1367391 in neutron "ML2 DVR port binding implementation unnecessarily duplicates schema and logic" [High,Confirmed] 16:33:44 This one I believe is a no brainer 16:33:47 This is a bug I filed to cleanup the distributed port schema and code, but I think we need to decide if its more than that 16:34:07 Do we see distirbuted ports being used for other services? 16:34:18 Like DHCP? 16:34:54 Are you envisioning distributed dhcp in the future? 16:34:55 rkukura: Currently I do not believe we have distributed DHCP, do we? 16:35:25 I think we can replicate the DHCP agent, but each replica eats a port and IP address, unless I’m mistaken 16:36:54 do the agents take ownership of coordinating dhcp address pool? 16:37:13 i think this has lot more implications... 16:37:54 maybe this is topic to discuss at the summit 16:38:32 Maybe ML2 should focus on the cleanup part of this, and I think we can make it more generalized in the process, and see where it might be used in the wider community 16:38:52 Any thoughts on whether a bug is sufficient for this, or if a BP is needed? 16:39:00 shivharis: In the earlier version of DVR proposal, somebody had mentioned this, but then no body followed up on this 16:39:43 Anybody see a use case for this? 16:40:18 If not, perhaps we can deal this with a bug for now 16:40:29 Lets stick with managing it as a bug for now, and maybe add a DB for using it in DHCP 16:40:33 rkukura: i am fine either way, just cleanup and not worry about dhcp for now 16:40:35 s/DB/BP/ 16:41:01 rkukura: +1 16:41:09 rkukura: agreed 16:41:19 ok 16:41:36 On to next item 16:41:48 Complete hierarchical port binding 16:42:02 I’ve started work on updating the Juno spec for Kilo. 16:42:06 #link: https://blueprints.launchpad.net/neutron/+spec/ml2-hierarchical-port-binding 16:42:33 And plan to sync it with the most recent version of the patch 16:42:53 we came close on getting this done in Juno - so, this should be easy to revive 16:43:07 +1 on hierarchical support 16:43:23 If anyone has any reservations about the approach taken in the patch, please speak up ASAP! 16:43:28 rcurran: I am with you on this one 16:43:42 actually i'm already using it and it works 16:44:12 That is a great authentication - thanks rcurran 16:44:38 rkukura: looks like we are good with this one... 16:44:45 ok 16:44:52 on to the next one 16:45:05 Solve the postcommit backend sync / error handling situation 16:45:26 #link: https://docs.google.com/document/d/17fATwZkJEonH0pIb1-mPD0UB5RKnJzcHYqkBesJhirE/edit 16:45:52 What do folks think about this? 16:45:58 There still seem to be a variety of possible approaches on the table for this 16:46:23 what is the best way to converge on this? 16:46:25 I think it is time to address this - it falls into the “technical debt” theme for kilo 16:46:27 imo: the error conditions should be set the same way (bulk or no bulk) 16:46:46 s/conditions/status/ 16:47:00 We also need to consider what might be done in the neutron core regarding TaskFlow, etc. 16:47:14 rkukura: yup! 16:47:36 has any other team used Tasks yet? 16:47:42 rkukura: at some time you were looking into TaskFlow, did you make any headway? 16:47:51 My suggestion is that we work to identify and understand the different appoaches, and include this in a wider discussion on tasks at the summit 16:48:12 cinder is using task flow I beleive... 16:48:18 Sukhdev: I did skim through the TaskFlow docs a couple weeks ago 16:48:19 actually we could also learn from some team that may have used it already? 16:49:01 I'm working with the person integrating into other project and might be able to help if anyone has questions. 16:49:18 afaik cinder already uses taskflow in the volume creation workflow. 16:49:21 manishg__: sounds good 16:49:26 manishg__: pointer please 16:49:54 shivharis, amotoki: I'll get more details 16:49:59 One big question would be whether to integrate TaskFlow at the core level, the ML2 plugin level, or the individual MD level? 16:50:08 amotoki, manishg__: thanks 16:50:47 rkukura: I am guessing at a transaction level 16:51:33 Sukhdev: I’m assuming lauching a task or seres of tasks would be part of the transaction that gets committed 16:51:41 amotoki: thanks for joining in - we had a question for you, but, will defer until the Open Discussion section 16:51:44 rkukura: yes. we need to explore more details. possiblly we can have multiple flow management instances. it depends on a situation. 16:52:05 rkukura: might be better to may start with small chunks…otherwise a large change I think. I'll also start thinking about it and we can discuss further 16:52:29 there has also been some discussion of allowing plugins to call each other from within transactions, which might mean all backend interaction should occur in async tasks outside the transaction. 16:53:03 How about discussing this on next weeks agenda? 16:53:14 rkukura: +1 16:53:29 rkukura: yes, this is a good idea 16:53:32 We’ve got 7 minutes, and 8 items to cover 16:53:52 lets go to next one 16:53:56 Complete the bulk ops support 16:54:23 banix is missing to discuss this 16:54:25 that seemed very close to merging in juno 16:54:40 Lets definitely complete this, but maybe it doesn’t need much discussion 16:55:02 hence, on to the next one - Revisit/cleanup/improve DB transaction usage, eliminating with_lockmode('update') and semaphore locking 16:55:38 This probably ties into core work as well, and the etherpad suggests tasks might be related 16:55:47 what involved in this? 16:56:29 I see the goal as removing the locking, but not sure what’s the best approach 16:57:01 rkukura: how best to approach this? 16:57:23 This probably does need discussion at the summit, since it crosses between plugins and core 16:57:41 * Sukhdev I am afraid we are running out of time 16:57:54 rkukura: you see anywhere is poorly done - or this is a general observation 16:58:23 Shall we take it in the next meeting? 16:58:31 My issue is that with_lockmode(“update”) leads to green thread deadlocks, and also this locking isn’t enforced in cluser DBs 16:58:37 cluster 16:58:42 I want to give couple of minutes for Open Discussion 16:58:50 Sukhdev: lets continue next week on these 16:58:56 #topic: Open Discussion 16:59:12 Can someone look at 16:59:12 https://review.openstack.org/#/c/118656/ 16:59:12 I need a second core reviewer 16:59:12 rkukura: we had a question for amotoki 16:59:29 hi 16:59:55 amotoki: yes, we noticed you are the only regular ML2 participant in neutron-drivers, so we are counting on you! 16:59:59 amotoki: we were concerned about ML2 representation 17:00:40 amotoki: are you going to be our (ML2 subteam) point person as a "neutron driver" 17:00:51 I think how neutron-driver team works and what will be the criteria is not decided yet. 17:01:04 I am glad to do. 17:01:21 amotoki: ++++++++ 17:01:22 amotoki: we are counting on you to fill that role 17:01:35 * Sukhdev Out of time folks 17:01:47 #endmeeting