16:03:29 <rkukura> #startmeeting networking_ml2
16:03:30 <openstack> Meeting started Wed Mar 12 16:03: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:03:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:34 <openstack> The meeting name has been set to 'networking_ml2'
16:04:15 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_March_12.2C_2014
16:04:37 <rkukura> #topic Action Item Review
16:04:55 <rkukura> No recorded action items - did I miss any?
16:06:27 <rkukura> I'm sure everyone's aware we are past feature freeze for icehouse and now just finding/fixing bugs for RC-1
16:07:22 <rkukura> #topic Final mechanism driver status for icehouse
16:07:28 <Sukhdev> rkukura: when is deadline for RC1?
16:07:49 <rkukura> markmcclain: Are you around for a definitive answer on that?
16:08:40 <rkukura> My understanding is that RC1 timing is driven by the set of targeted bugs
16:08:47 <matrohon> where can we find a list of FFE accepted for neutron?
16:10:07 <rkukura> matrohon: Bps in https://launchpad.net/neutron/+milestone/icehouse-rc1 that aren't in Implemented state should have FFEs
16:10:23 <Sukhdev> OK - I will keep monitoring. I have a bug to submit - wanted to make sure that I hit within deadline
16:10:54 <matrohon> because we didn't have any answer for the FFE request we asked on the ML for HA VRRP
16:11:01 <rkukura> Sukhdev: File the bug ASAP and target icehouse-rc1
16:11:22 <Sukhdev> rkukura: will do - thanks
16:12:00 <rkukura> matrohon: I suggest asking markmclain about specific FFEs
16:12:15 <matrohon> rkukura : ok thanks
16:12:26 <rkukura> For bug fixes, getting code into review this week is a good goal
16:13:48 <rkukura> #topic Other BPs for icehouse
16:14:38 <rkukura> The one open FFE for ML2 I'm aware of is marun's migration script: https://review.openstack.org/#/c/76533/
16:15:08 <rkukura> This is critical to allow deprecation of the old monolithic openvswitch and linuxbridge plugins.
16:15:43 <rkukura> Please, if you can, test it and review it.
16:16:43 <rkukura> I don't think the partial specs BP got an FFE
16:17:03 <rkukura> Anything else on BPs or FFEs?
16:17:35 <rkukura> #topic Bugs for icehouse
16:18:22 <rkukura> I expect to complete the final part of the port binding details bug today
16:18:47 <rkukura> #link https://bugs.launchpad.net/neutron/+bug/1276395
16:18:49 <shivharis> if possible please add ml2 tag to the bugs, for easy searching
16:18:57 <rkukura> shivharis: +1
16:19:54 <rkukura> The initial part of the bind_port() in transactions fix is in review
16:20:14 <rkukura> #link https://review.openstack.org/#/c/79511/
16:21:00 <rkukura> This removes the validate_port_binding() and unbind() port calls from the MD API.
16:21:09 <rkukura> make that unbind_port()
16:22:20 <rkukura> I realized that, now that we don't need to call unbind_port() in delete port, finishing up the port binding details bug fix is trivial, so I'm handling that in this patch.
16:22:51 <rkukura> The patch to move bind_port() outside the transaction should be ready today, or tomorrow at the latest.
16:23:15 <matrohon> rkukura : so it won't be possible to operate live-migration, with a host on ovs and a host on lb, which both use the same generic vif_driver? if you remove validate_port_binding?
16:23:49 <rkukura> matrohon: How is that?
16:24:23 <matrohon> rkukura : as i understand your commit message, the port can't be rebound to another MD withour validate_port_binding?
16:24:55 <rkukura> matrohon: Change binding:host_id will still force rebinding
16:25:15 <matrohon> rkukura : ok
16:26:51 <rkukura> matrohon: Lets make sure this is OK. Eventually we may want something like validate_port_binding if nova can actually respond to updates being pushed to it. But right now, spontaneously rebinding does not seem to serve any useful purpose, and could cause problems if the binding changes but nova is still using the vif_type and vif_details from the old binding.
16:27:34 <rkukura> banix: Your error handling for update_*_postcommit() ops is in review
16:27:58 <banix> rkukura: OK, thanks.
16:28:00 <rkukura> #link https://review.openstack.org/#/c/69792/
16:28:04 <matrohon> rkukura : i'm fine with that, and this use case might be handle by an entire BP, which include nova part
16:28:14 <rkukura> matrohon: +1
16:28:15 <irenab> matrohon: I guess for live migration, libvirt may require same VM XML
16:29:01 <rkukura> The error handling patch still needs ML2 and core reviewers.
16:29:44 <matrohon> irenab : not sure, but this is a question which might be explored during the implementation of a new BP
16:29:49 <banix> Regarding update_*_postcommit patch, markmcclain and others had made a few suggestions a few days back and I made the adjustments.
16:30:02 <rkukura> banix: Do you feel this is ready for use, or do you think we should consider deferring it to juno?
16:30:45 <banix> rkukura, I thin it is ready for use but it is not crucial for the operation of ML2 so it is your call.
16:30:53 <rkukura> Right now, I think failures in the update_*_postcommit ops are logged and ignored, and this patch tries to undo the updates instead.
16:31:04 <banix> Mark marked it as targeted for RC1
16:32:31 <rkukura> banix: I haven't given this a close review yet, but have a question
16:34:28 <rkukura> Since all registered MDs will have seen an update_*_precommit prior and some may have seen an update_*_postcommit, do they all see the undo as a new update with its own update_*_precommit and update_*_postcommit ops?
16:36:01 <rkukura> If we are going to include this fix in RC1, I'd like to make sure MD authors understand how the failures are handled and make sure it won't cause any issues.
16:36:21 <banix> no, the undo is done by the plugin code. I see what you say.
16:37:52 <rkukura> I'll take a closer look today, and we need some ML2 MD authors to review as well.
16:38:21 <banix> ok; yes makes sense to be cautious this late in the game
16:38:37 <rkukura> I listed 4 other bug targeted at RC1 in the agenda
16:39:35 <rkukura> nati_ueno's VIF security fix involves ML2 as well as other plugins
16:39:51 <rkukura> #link https://bugs.launchpad.net/nova/+bug/1112912
16:40:19 <rkukura> This is really important to get into icehouse so that security groups work again!
16:40:43 <rkukura> Please review if you can.
16:41:23 <rkukura> There is a bug on binding failures during tempest tests
16:41:37 <rkukura> #link https://bugs.launchpad.net/neutron/+bug/1244255
16:42:15 <rkukura> Its unassigned, so does anyone want to look into this one?
16:42:37 <rkukura> It may just be timing issues with agent_db info not being available, but is probably worth investigation
16:43:22 <rkukura> Adding agent_db model migration for ML2 is in review at https://bugs.launchpad.net/neutron/+bug/1260224
16:44:28 <rkukura> And a L2-pop live migration fix is in review at https://review.openstack.org/#/c/61767/, and will be rebased soon.
16:44:43 <matrohon> actually I just rebased it
16:44:51 <matrohon> but i lost my +2 :(
16:45:00 <rkukura> Are there any other ML2-related bugs for icehouse?
16:45:31 <rkukura> I know Sukhdev has one to file and fix.
16:45:39 <matrohon> I have this one
16:45:42 <matrohon> https://bugs.launchpad.net/nova/+bug/1282956
16:46:21 <matrohon> but to me it's more a nova issue, which doesn't send port_update after evacuating a host
16:47:40 <rkukura> matrohon: Do you think a neutron-side fix is needed?
16:49:02 <matrohon> rkukura : to me, i think that a patch in nova should resolv it
16:49:20 <rkukura> ok
16:49:34 <rkukura> anything else on bugs?
16:49:52 <rkukura> #topic Distributed Virtual Router
16:50:10 <rkukura> Any update on this today?
16:50:57 <rkukura> #topic Juno design summit session proposals
16:51:23 <Sukhdev> rkukura: I reviewed DVR spec - looks good
16:51:31 <rkukura> Time to start thinking about design summit sessions, and submitting proposals at http://summit.openstack.org/
16:52:14 <rkukura> I'm planning to enter one for a general update/planning/catch-all session for ML2
16:52:35 <rkukura> We can use that to address unfinished items from icehouse that don't have their own sessions
16:53:01 <rkukura> But I'd suggest everyone submit specific sessions for anything they feel is important to do in juno
16:53:18 <Sukhdev> rkukura: I am thinking ML2 type driver for late-binding support
16:54:07 <Sukhdev> rkukura: that is the segment ID assignemnt is deferred until the VM is launched - as opposed to assigning it upfront at time of network creation
16:54:34 <Sukhdev> rkukura: Do we have anything like that already?
16:54:36 <rkukura> Sukhdev: sounds interesting - Is this for the host<->ToR switch segment?
16:55:08 <Sukhdev> rkukura: yes - but, could be for over all multi-segmented network
16:55:31 <rkukura> We only have 5 minutes left, so lets plan to kick around some session ideas next at next weeks meeting
16:55:47 <rkukura> Please don't hesitate to submit session ideas in the mean time.
16:55:53 <Sukhdev> rkukura: e.g. two VMs boot at different times at two different clustors, get ID assignement as they come up
16:56:37 <rkukura> Hopefully bugs and FFEs will be winding down next week and we can reserve most of the meeting to kick around ideas
16:56:52 <rkukura> Anything else on summit sessions right now?
16:57:01 <rkukura> #topic Open Discussion
16:57:14 <Sukhdev> rkukura: what is the deadline for submission?
16:57:37 <Sukhdev> rkukura: do we have to have prototype working for the submissions?
16:57:39 <banix> this friday i think
16:57:55 <rkukura> Didn't realize it was so soon
16:58:17 <Sukhdev> me too - its kinda tight...
16:58:32 <banix> the date may be wrong. please ignore.
16:58:48 <Sukhdev> banix: :-)
16:59:11 <HenryG> I don't think a deadline has been specified yet
16:59:13 <rkukura> If so, lets get them submitted, and we can discuss next Wednesday and maybe make some suggestions on what to combine, etc.
16:59:27 <rkukura> We are out of time
16:59:31 <rkukura> Anything else?
16:59:41 <banix> It starts on Tuesday morning and ends on Friday evening.
16:59:50 <rkukura> Please keep up the reviews!
16:59:51 <banix> so i think it is this friday
16:59:56 <rkukura> #endmeeting