16:01:09 <rkukura> #startmeeting networking_ml2
16:01:10 <openstack> Meeting started Wed Jul 30 16:01:09 2014 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:13 <openstack> The meeting name has been set to 'networking_ml2'
16:01:36 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Agenda
16:01:52 <rkukura> #topic Announcements
16:02:15 <rkukura> Hope to make this a relatively quick meeting today
16:02:28 <rkukura> I don’t have any announcements - does anyone else?
16:02:48 <yamamoto_> nothing from me
16:03:00 <trinaths> nothing
16:03:07 <rkukura> #topic Bugs
16:03:13 <shivharis> hi
16:03:18 <rkukura> shivharis: Do you have an update for us?
16:03:32 <shivharis> i need someone to pick up this bug, it is still in unassigned state...
16:03:37 <shivharis> https://bugs.launchpad.net/neutron/+bug/1327127
16:03:38 <uvirtbot> Launchpad bug 1327127 in neutron "neutron: infinite loop in port create (qpid/ML2 ovs) - Icehouse" [High,Confirmed]
16:04:00 <shivharis> can someone attending do so?
16:04:28 <shivharis> ok, i am going to assign then
16:04:57 <shivharis> bug status?https://bugs.launchpad.net/neutron/+bug/1311470
16:04:58 <uvirtbot> Launchpad bug 1311470 in neutron "Disabling an ML2 type driver can leave orphaned DB records" [Medium,Confirmed]
16:05:11 <shivharis> navin?
16:05:33 <Sukhdev> shivharis: on the first one, it seems like there is workaround in place
16:06:05 <shivharis> Sukhdev: can you update status, we can go from there
16:06:27 <Sukhdev> shivharis: let me follow up on that
16:06:32 <shivharis> Sukhdev: please add your comments, thanks
16:06:40 <shivharis> Sukhdev: thanks
16:06:50 <shivharis> Any other questions on bug?
16:06:55 <shivharis> bugs?
16:06:56 <rkukura> I’m not sure there is a lot we can do about the orphaned DB records
16:07:38 <shivharis> Orphanded records can have a negative impact on "sync"
16:08:09 <rkukura> Maybe disabling an “in-use” type driver should be considered operator error
16:08:49 <rkukura> Maybe we need a way to disable new segments of a type from being created without actually unconfiguring the driver
16:09:12 <shivharis> rkukura: can you please add your comments in the bug, so we have a place to discuss
16:09:18 <rkukura> shivharis: OK
16:09:26 <shivharis> rkukura: thanks
16:09:33 <yamamoto_> i suggest to put https://bugs.launchpad.net/neutron/+bugs?field.tag=ml2 on agenda as we decided to tag ml2 related bugs so while ago.
16:09:33 <Sukhdev> rkukura: makes sense
16:09:34 <shivharis> folks thats all i have on bugs this time.
16:09:38 <rkukura> #action rkukura to add comments to https://bugs.launchpad.net/neutron/+bug/1311470
16:09:39 <uvirtbot> Launchpad bug 1311470 in neutron "Disabling an ML2 type driver can leave orphaned DB records" [Medium,Confirmed]
16:09:52 <rkukura> anything else on bugs?
16:10:04 <rkukura> #topic Code Reviews
16:10:20 <rkukura> #undo
16:10:20 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x2648a50>
16:10:28 <rkukura> #topic Spec Reviews
16:10:57 <rkukura> We are now well past the SAD - does anyone know of any unapproved ML2 specs that are candidates for exceptions?
16:11:26 <Sukhdev> rkukura: last week I made a case for two of Rich's specs
16:11:40 <yamamoto_> portsecurity one?
16:11:43 <rkukura> Right
16:12:09 <Sukhdev> I do not think they made it
16:12:10 <rkukura> Are these blocked on reviews right now, or just on mestery granting exceptions?
16:12:45 <Sukhdev> they were blocked on reviews - but, now, I believe they should be unblocked
16:12:57 <mestery> FYI: We're well past exception at this point. I'm unlikely to approve any new specs.
16:13:06 <mestery> We have 84 approved for 5 weeks of the cycle left.
16:13:08 <Sukhdev> Rich was on PTO - Henry has been filling in for him
16:13:10 <mestery> That's about 14 to merge a week.
16:13:16 <mestery> Which is impossible :)
16:13:27 <rkukura> OK, so these should be considered deferred until Kilo I guess
16:13:33 <mestery> rkukura: +1
16:13:58 <Sukhdev> Sounds fine - wanted to give it a final push/plea :-)
16:14:03 <rkukura> I think that makes sense for port security, allowing it to be implemented as an exception driver, assuming that makes Juno
16:14:39 <rkukura> Maybe some aspects of Rich’s specs could be treated as bug fixes rather than new features?
16:15:15 <Sukhdev> rkukura: I doubt it
16:15:15 <BrianB_> We need Rich changes so we can depericate the cisco plugin
16:16:21 <Sukhdev> rkukura, BrianB_: from the spec it looks like a new feature - hence will have to wait until Kilo
16:17:16 <BrianB_> sukhdev: it;s for feature parity
16:17:33 <rkukura> BrianB_: I think parity issues between a plugin and a driver might be treated as bugs
16:18:10 <Sukhdev> BrianB_: are you referring to L3 Service Plugin spec?
16:18:35 <Sukhdev> BrianB_: If yes, that is a new feature for Neutron - not a parity issue
16:19:01 <BrianB_> Sukhdev: yes specficly the SVI is parity,
16:19:31 <rkukura> OK, lets move on
16:20:05 <Sukhdev> BrianB_: I rather see the spec getting approval as oppose to dealing it with as a bug
16:20:23 <rkukura> Should we update https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews and use it for tracking Juno code reviews from this point forward?
16:21:12 <Sukhdev> rkukura: yes, we should. I updated it last week the status of spec approvals - now we should use it for core reviews
16:22:01 <Sukhdev> rkukura banix put in a good work into it, we should use it :-)
16:22:03 <rkukura> OK, if “Specs Under Review” is up to date, it probably should be renamed to “Deferred Specs”
16:22:03 <shivharis> rkukura: +1
16:22:43 <Sukhdev> rkukura: agreed
16:22:44 <rkukura> #topic Code Reviews
16:23:05 <mxu> Hi  rkukura,   I assume  the owners of the code should updae https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews, correct?
16:23:18 <Sukhdev> rkukura: you can assign an action to me or banix to update that table
16:24:06 <rkukura> #action Sukhdev and banix to update https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews with deferred specs and for tracking code reviews for approved specs
16:24:44 <rkukura> Are there any code reviews that need discussion today?
16:26:07 <rkukura> OK, lets try to keep up with subteam code reviews, and make sure code is in pretty good shape before asking for core reviews.
16:26:39 <rkukura> Also, we need to focus on higher priority reviews, but not ignore the vendor-specific patches eitehr
16:26:43 <rkukura> ether
16:26:52 <rkukura> either (sorry can’t type today)
16:27:10 <Sukhdev> rkukura: makes sense
16:27:30 <rkukura> #topic ML2 Hierarchical Port Binding and Dynamic Segments
16:28:50 <Sukhdev> I started to review the document last night and fell asleep - could not finish reading it
16:29:04 <Sukhdev> Will read it today
16:29:37 <Sukhdev> rkukura: are we almost converged on it?
16:29:40 <banix> is there a link?
16:29:41 <rkukura> There are a couple of approved blueprints that, together, allow mechanism drivers for switches to dynamically manage segments (typically VLAN) that are then bound with other mechanism drivers (openvswitch, …) at the host level.
16:29:56 <Sukhdev> banix:yes
16:29:59 <rkukura> #link https://blueprints.launchpad.net/neutron/+spec/ml2-hierarchical-port-binding
16:30:14 <rkukura> #link https://blueprints.launchpad.net/neutron/+spec/ml2-type-driver-refactor
16:30:26 <banix> thanks
16:30:58 <Sukhdev> Here is link to Bob's doc on the subject https://docs.google.com/a/arista.com/document/d/1rqTHiLgV_3bw3nbiggY_xM-xETDsw0aK5rZZVXopSU8/edit#heading=h.3gt7q76urxew
16:31:38 <rkukura> I’ve been working the past week to try to get some concensus among the mechanism driver authors that will take advantage of this on what network_type values and corresponding TypeDrivers are needed, etc.
16:31:59 <rkukura> It would be helpful to know which mechanism drivers are likely to use this in Juno or in Kilo
16:32:34 <rkukura> And try to document how the pieces fit together in the Google doc that Sukhdev mentioned
16:32:48 <Sukhdev> rkukura: Juno is too early for us. I will most likely use it in Kilo
16:33:20 <padkrish> i will evaluate it and respond back...my code for VDP is posted for review
16:33:22 <rkukura> I believe Cisco plans to use this in the DFA and APIC mechanism drivers in Juno if possible
16:33:46 <padkrish> rkukura# right
16:34:35 <Sukhdev> So, if there are takers for this in Juno, we should prioritize it and get a quick closure
16:34:37 <rkukura> asomya has a WIP patch for the type driver refactor that I’d really like the subteam to look at closely: https://review.openstack.org/#/c/110404/
16:35:48 <rkukura> From my perspective, the main requirement for the type driver BP/patch is to allow allocation of the dynamic VLAN segments.
16:36:47 <rkukura> We need to decide whether the refactoring to let type drivers manage their own property storage is needed for this, should be included with this, or should be handled separately, possibly in Kilo
16:37:05 <Sukhdev> padkrish rkukura: have you thought about the CLI implications of this?
16:37:32 <Sukhdev> I.e. how will one create multi-segmented networks from Neutron API?
16:37:57 <rkukura> It seems zzelle’s partial specs code that merged can do some of what’s needed, by specifying the network_type and physical_network, allowing the segmentation_id to be allocated.
16:38:47 <rkukura> Sukhdev: I think the CLI can be used to create multi-segment networks with arbitraty properties, but how/whether those show up in the providernet attributes remains to be determined
16:39:53 <rkukura> I hope to get working on the actual hierarchical binding code in the next couple days, but have been waiting for the DVR patches that reorganize much of this code to merge first (if they are going to).
16:40:11 <rkukura> armax has been doing a lot of good work on this
16:40:53 <armax> rkukura: yes, I have another merge conflict to go through :)
16:41:24 <rkukura> Expect some emails in openstack-dev related to the hierarchical binding and dynamic segments in the next few days
16:41:35 <armax> rkukura: I keep getting sidelined, but I should be able to get there soon enough
16:41:58 <rkukura> armax: Same here - will catch up on the outstanding reviews
16:42:04 <armax> rkukura: :)
16:42:07 <rkukura> Anything else on this topic?
16:42:19 <rkukura> #topic Open Discussion
16:42:27 <amotoki> I have a question on VDP review. VDP support is a kind of dynamic VLAN segment support (hierarychcal binding) and both are tackling similar area (though I haven't reviewed enough).
16:42:39 <amotoki> how do we coordinate these efforts?
16:43:30 <padkrish> amotoki# Hierarchical binding concept is general. VDP is one way of doing hierarchical binding
16:43:42 <rkukura> amotoki: We’ve been discussing a plan to introduce a “vdp_vlan” network type that gets used as a dynamic segment to indicate that VDP should be used to negotiate the VLAN.
16:44:16 <amotoki> rkukura: it sounds reasonable.
16:44:31 <rkukura> amotoki: The get_device_details RPC would return this to the L2 agent once its been bound by the openvswitch mechanism driver
16:44:59 <rkukura> And the openvswitch agent would then trigger the negotiation.
16:45:28 <rkukura> Anything else for today’s ML2 meeting?
16:45:43 <amotoki> rkukura: the behavior is same as what I think and perhaps i discussed it with padkrish in the spec reivew. thanks.
16:45:58 <padkrish> #amotoki# yes
16:46:29 <yamamoto_> nothing from me
16:46:39 <rkukura> The use of dynamic segments for VDP should be addressed in the google doc that Sukhdev linked
16:46:45 <rkukura> anything else?
16:46:56 <rkukura> If not, lets wrap up a bit early
16:47:07 <rkukura> #endmeeting