16:04:13 <rkukura> #startmeeting networking_ml2
16:04:14 <openstack> Meeting started Wed Mar 26 16:04:13 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:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:17 <openstack> The meeting name has been set to 'networking_ml2'
16:05:00 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_March_26.2C_2014
16:05:12 <rkukura> agenda is kind of light today
16:05:46 <rkukura> no official action items from last week
16:06:01 <TrinathSomanchi> when will the devtree for juno be opened.  ?? any idea
16:06:03 <yamamoto> hi
16:06:22 <rkukura> TrinathSomanchi: I’m not sure, anyone know?
16:06:37 <rkukura> #topic Migration BP
16:06:47 <amotoki> TrinathSomanchi: After RC1 is shipped
16:06:51 <rkukura> This merged - good job marun
16:07:25 <amotoki> yeah. I hope more people tests it :-)
16:07:29 <rkukura> Lets continue to test this and make sure migrations from other plugins to ML2 in icehouse will go smoothly
16:08:00 <rkukura> Any comments/questions on the migration tool?
16:08:03 <TrinathSomanchi> amotoki: RC1 of icehouse ?? any tentative dates for Juno..
16:08:37 <TrinathSomanchi> in nova mailing lists, I hear about gerrit for BP review. Do the same procedure be followed in Neutron from Juno ..
16:09:11 <amotoki> TrinathSomanchi: could you wait for open discussion about juno topic?
16:09:25 <TrinathSomanchi> okay
16:09:26 <rkukura> #topic icehouse bugs
16:10:32 <rkukura> The port binding details fix is now completely merged, and the Cisco nexus driver has been updated by rcurran to remove the workaround. Other drivers may also be able to do the same.
16:11:41 <rkukura> The patch moving port binding outside of transactions is now in WIP review
16:12:01 <rkukura> #link https://review.openstack.org/#/c/82945/
16:12:08 <rcurran> rkukura, is your goal to get this WIP into Icehouse?
16:12:27 <rkukura> I plan to update this later today with some clean ups (mostly identified by REVISIT comments)
16:12:58 <matrohon> route -n
16:13:06 <matrohon> ha sorry :)
16:13:19 <rkukura> It would be great if others could start looking this over and providing feedback
16:13:47 <rkukura> Hopefully we’ll get a decison soon on whether it makes icehouse or gets deferred
16:14:21 <rcurran> rkukura, ok - i'll wait until your next patch before i review in more detail
16:14:47 <rkukura> rcurran: I’d encourage feedback on the current patch if possible so it can be incorporated into the update
16:15:00 <rkukura> The current patch seems to pass all the Jenkins testing
16:15:46 <rcurran> rkukura, yeah i'm sure it works and if we're under the clock for a commit then i don't have an issue in +1 but thinking i would change some of the ut/control plane changes in the future
16:15:50 <rkukura> In particular, I have some revisit comments on changes to the mechanism drivers and tests that I’d like to remove in the cleanup once the driver authors have looked them over
16:16:20 <rkukura> rcurran: Yes, at this point we need to minimize unnecessary change
16:16:32 <rkukura> Anything else on the port binding bugs?
16:17:04 <rkukura> banix: Any update on https://bugs.launchpad.net/neutron/+bug/1227336?
16:17:39 <rkukura> This is the improved error handling when postcommit methods raise exceptions
16:17:51 <banix> rkukura, I think last week we decided to leave this for after Icehouse
16:18:17 <banix> mestery suggested we discuss some of the related issues at the sumit
16:18:28 <rkukura> banix: I think that’s a reasonable plan - lets continue to review this and see if the stratefy makes sense
16:18:38 <amotoki> my question is whether we need to update the status.
16:18:40 <banix> thee is no clean and unified way of undoing what mechanism drivers may have done in a precommit  op
16:18:49 <rkukura> s/stratefy/strategy/
16:19:31 <rkukura> banix: I’m wondering if exceptions in postcommit should be logged and returned, but otherwise non-fatal
16:19:47 <banix> amotoki: status for the bug?
16:20:18 <rkukura> I think markmclain took the icehouse-rc1 target off it
16:20:19 <amotoki> banix: no. status of resources (port, ..)
16:20:29 <banix> rkukura, but if you don't do anyhing you are left with inconsistent state
16:20:59 <banix> rkukura, unless you mean wrt the mechanism drivers
16:21:08 <Sukhdev> banix: can you elaborate on that?
16:22:02 <rcurran> from a vendors perspective (and admin of the openstack deployment using a cisco md) an exception in postcommit is as important to note as a db failure
16:22:03 <banix> So by the time the post commit fails you have made changes to say for example allowed address pairs
16:22:52 <banix> there are two sets of things that one need to worry about: the state of the plugin and then that of the mechanism drivers
16:23:03 <amotoki> IMO when postcommit fails, there are several options: (1) set resource status to ERROR, (2) return an exception, (3) 1 & 2.   (no signal should be avoided)
16:23:35 <banix> wri the plugin, my patch essentially undo the changes that do not get undone automatically
16:24:05 <banix> wrt the mechanism drivers, some change state in the precommit part of the operation that ideally need to be undone
16:24:24 <rkukura> banix: Does the curren patch also undo the changes from the perspective of the MDs that have seen the changes prior to the exception?
16:24:46 <banix> the current patch does not do anything wrt the MDs
16:25:06 <banix> that part is missing and it is not clear to me what the best approach is for dealing with it
16:25:38 <banix> mechanism drivers differ in how they keep states and how that changes in precommit ops. does this make sense?
16:26:04 <banix> sukhdev: did I ansewr your question
16:26:11 <Sukhdev> banix: thanks - yes
16:26:48 <rkukura> Assuming we don’t get this fixed in icehouse, it seems like something we’d want to complete quickly and potentially backport
16:26:49 <Sukhdev> banix: Two points - I thougth a failure triggers a rollback - and hence delete will follow
16:27:22 <Sukhdev> banix: secondly, I clean up all these inconsistencies in the sync mechanism in MD
16:27:35 <banix> sukhdev: no rollback as post commits are not called within transactions
16:28:10 <banix> sukhdev: to your second point, may be that is the approach to take but not all mech drivers do that
16:29:01 <banix> sukhdev: the troble is with update operations
16:29:17 <Sukhdev> banix; If no rollback, then I see this as an issue - I aways thought there was a rollback - perhaps I never noticed the issues because of the sync mechanism :-)
16:30:03 <Sukhdev> banix: I am with you now - thanks for clarification
16:30:13 <banix> So I gues the question is if there should be a general mechanism that mechanism driver should include for addressing this issue
16:31:04 <Sukhdev> banix: sync solves all these issue :-)
16:31:09 <banix> One suggestion by rkukura was calling the precommit again with original data but that won't work
16:31:35 <banix> sukhdev,  is sync required by mechanism drivers?
16:31:38 <Sukhdev> Use Neutron DB as "true-source" and build a sync mechanism - you will never go wrong :-)
16:32:00 <rkukura> banix: Wouldn’t an undo of an update require precommit calls that reverse the changes?
16:32:40 <rkukura> Seems like a plugin-level sync mechanism would be a good summit topic
16:32:41 <banix> rkukura: you won't get the undo effect by calling the precommit with original data necessarily
16:33:03 <banix> rkukura: I think that is what mestery was suggesting last week as well
16:33:09 <Sukhdev> rkukura; Agree - I can work with you on this if you want
16:33:27 <amotoki> I think a complete rollback is not easy. reverting to this original data can override a data by another update during postcommit.
16:33:29 <amotoki> agree.
16:33:55 <banix> amotoki: right
16:34:06 <amotoki> do we have a consensus what is needed in icehouse? status? exception? no changes from now?
16:34:32 <rkukura> So maybe we need some way to mark the resource as needing a resync, and having the plugin periodically call into the drivers to take care of this, using the current DB state at that time.
16:34:49 <Sukhdev> rkukura: +1
16:34:51 <banix> I think mestery was thinking od having a session which include various ML2 related issues including this one...
16:35:11 <amotoki> +1. i think setting ERROR is a good start.
16:35:50 <banix> Should we then leave the plugin as is for now?
16:36:05 <Sukhdev> banix: I say - yes
16:36:06 <rkukura> In an update in the current code, does an exception raised in postcommit by one MD prevent the other MDs from being called?
16:36:23 <rcurran> rkukura, yes
16:36:47 <Sukhdev> Oh - that is bad -
16:36:49 <banix> amotoki: do you think we should add your suggestion in Icehouse or defer to a better solution in Juno?
16:36:50 <rcurran> failures on deletes are best effort and all md's will be called
16:37:11 <rcurran> create postcommit failures result in delete being called
16:37:17 <rkukura> Would a short term fix to at least call the other MDs before returning the exception help?
16:37:25 <rcurran> update postcommit cause an exception
16:37:28 <amotoki> banix: let me check the code. If no indication it is not a good thing.
16:37:37 <rkukura> I don’t think a failure in update results in a delete
16:37:43 <rkukura> I think that was just in create
16:37:44 <rcurran> correct
16:38:54 <banix> yes in update we just have: self.mechanism_manager.update_network_postcommit(mech_context)
16:39:17 <banix> no error handling right now
16:39:54 <rkukura> So the current behavior is that the error gets logged and returned from the update, and that subsequent MDs never see the postcommit
16:40:19 <rcurran> rkukura, correct -logged and exception raised
16:40:22 <banix> yes
16:41:00 <rkukura> I think the logging and returning the exception are OK, but I’m concerned about subsequent MDs not seeing the postcommit. What do others think about this?
16:41:41 <rkukura> Would a simple fix to call the remaining MDs before returning an exception be helpful?
16:41:57 <Sukhdev> rkukura: I think your idea of short term fix of calling all MDs should take care of this - until a long term soln is put in place
16:42:48 <banix> rkukura: I can address that in a new patch and all can review
16:43:21 <rkukura> #action: banix to push patch to call remaining MDs after postcommit exception
16:43:26 <amotoki> it sounds reasonable for icehouse.
16:43:32 <banix> should be straigh forward enough so should have it by the end of day
16:43:34 <rcurran> i don't object to having all postcommits called on a single md failure. just as long as an exception is raised
16:43:45 * banix note to myself: nothing is straightforward :)
16:43:47 <rcurran> update postcommits that is
16:44:02 <rkukura> OK, anything else on this bug?
16:44:11 <rkukura> Last agenda item is the VIF security issue
16:45:32 <rkukura> amotoki: You’ve been in the IRC and email threads on this. Can you update us on the current status/plan?
16:45:59 <amotoki> First of all, IRC meeting about hybrid dirver secgroup issue will be held today.
16:46:36 <amotoki> the original patch https://review.openstack.org/#/c/21946/ is too complicated and another solution is being discussed.
16:46:41 <rkukura> amotoki: Is that still scheduled for 14 minutes from now?
16:47:04 <amotoki> I don't see any update from nachi's mail.
16:47:31 <amotoki> In the meeting, nova and neutron folks will discuss it according to the mail.
16:48:09 <amotoki> I am not sure which MD depends on Hybrid drivers.
16:49:11 <amotoki> Maintainers of MD which depends on hybrid driver needs to keep eyes on this topic.
16:49:11 <rkukura> Clearly the openvswitch agent’s MD does, and non-binding MDs don’t
16:50:13 <amotoki> At now, there are several options in the review and thread. new review is https://review.openstack.org/#/c/82904/.
16:50:51 <amotoki> I see NeturonFirewallVIFDriver, new VIF type, vif_security attribute, ....
16:51:37 <rkukura> This is all sounding just as complicated, if not more, than the plan we had to use vif-details
16:52:07 <rkukura> I’m not clear why we shouldn’t just use vif-details with the current single flag
16:52:37 <rkukura> The nova changes to put vif-details in the VIF object are straightforward, and the GenericVIFDriver can than use that flag.
16:52:37 <yamamoto> ofagent currently depends on hybrid driver. (same as ovs)  but we want to switch to flow-based implementation for a long term.
16:53:07 <rkukura> And this the has things in place to provide finer grained control as in the original patch from Nachi
16:53:47 <amotoki> rkukura: yes. the point is how to inform iptables is required. What I can say now is that a single attribute is not sufficient.
16:54:08 <rkukura> s/And this the has things in place/And this puts the things in plance/
16:55:36 <amotoki> I think vif_detail is a good way.
16:55:37 <rkukura> amotoki: Is the VIF details discussion on #openstack-neutron?
16:55:43 <amotoki> yes.
16:55:54 <rkukura> Lets wrap up this meeting, and continue there
16:56:01 <rkukura> thanks amotoki!
16:56:23 <rkukura> #topic Open Discussion
16:56:43 <amotoki> another note: please keep watching on removing db-schema auto-generation patch: https://review.openstack.org/#/c/40296/
16:57:13 <rkukura> amotoki: Is this going into RC1?
16:57:36 <amotoki> not sure, but I think it is almost ready.
16:57:37 <Sukhdev> I have a quick question - How does ML2 deal with the VM Migration? Do we support it? If yes, does it come down as update_port() or delete followed by create?
16:57:47 <irenab> amotoki: feels like something that should not be on the last minute
16:58:42 <rkukura> Sukhdev: I think its seen as a port update that changes binding:host_id, but am not positive how nova handles
16:58:42 <rkukura> it
16:58:46 <amotoki> irenab: we gave up this in Havana at the last moment... Icehouse too? i am not sure.
16:58:49 <rkukura> Anyone else?
16:59:14 <rkukura> Last minute - anything else?
16:59:29 <Sukhdev> rcurran: you had a patch on VM migration, can you please answer?
16:59:53 <rcurran> sorry - on two meetings
17:00:02 <rcurran> reading back
17:00:20 <rcurran> cisco nexus md doesn't change binding_host_id
17:00:38 <rkukura> thanks everyone!
17:00:44 <amotoki> thanks!
17:00:46 <rkukura> #endmeeting