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