16:02:02 <mestery> #startmeeting networking_ml2 16:02:03 <openstack> Meeting started Wed Jan 8 16:02:02 2014 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:06 <openstack> The meeting name has been set to 'networking_ml2' 16:02:12 <mestery> #link https://wiki.openstack.org/wiki/Meetings/ML2 Agenda 16:02:25 <mestery> So, welcome back from the holidays everyone! 16:02:56 <mestery> We've got an agenda heavily focused on bugs and Binding Management today. 16:03:07 <mestery> But first, lets cover action items from the previous meeting 3 weeks ago. 16:03:10 <mestery> #topic Action Items 16:03:19 <mestery> asadoughi: Thanks for sending out UT coverage! 16:03:31 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/022649.html ML2 Unit Test Coverage 16:03:34 <asadoughi> mestery: no problem. 16:03:58 <asadoughi> the most useful one to look at now, i think, is the sorted and filtered output http://paste.openstack.org/show/55375/ 16:04:16 <mestery> #link http://paste.openstack.org/show/55375/ Sorted and filtered ML2 UT Coverage 16:04:16 <asadoughi> so, at the bottom, you'll see what's lacking the most line coverage 16:04:20 <mestery> Thanks asadoughi! 16:04:45 <mestery> asadoughi: Would you mind filing a bug (or bugs) to track the things we need to add coverage for? 16:04:59 <rkukura> +1 16:05:08 <asadoughi> mestery: a bug per row in the file? 16:05:18 <asadoughi> mestery: threshold? 16:05:50 <mestery> That would be a large number of bugs, but would allow for splitting things up quite well :) 16:05:54 <mestery> rkukura: Thoughts on bug per row? 16:06:11 <rkukura> should be possible to look over the files and see if the lines not covered should be, or if they are code that really should never execute 16:06:30 <rcurran> i was planning on fixing all drivers/cisco under one bug 16:07:06 <mestery> rcurran: Thanks! Is there a bug for that? If not, please file one. 16:07:11 <asadoughi> ok, i can aggregate the ones like that 16:07:18 <asadoughi> into one bug 16:07:25 <mestery> asadoughi: Thanks! 16:07:27 <rcurran> i thought i did. if not then i'll create one 16:07:38 <mestery> #action rcurran to verify if a bug exists for Cisco ML2 UT coverage 16:07:54 <mestery> #action asadoughi to verify UT coverage and file bugs for appropriate areas 16:07:56 <mestery> OK, lets move on now. 16:08:01 <rkukura> if the issues with the type drivers are similar, you could aggregate those 16:08:09 <mestery> #topic Binding Management 16:08:15 <asadoughi> ok, sounds good 16:08:35 <mestery> So, rkukura and I were chatting about this yesterday. 16:08:48 <mestery> We have some issues around the binding which we wanted to discuss here. 16:08:55 <mestery> rkukura: Thanks for adding some items to the agenda there. :) 16:09:42 <Sukhdev> can I ask a question? 16:10:17 <rkukura> Sukhdev: you just did! 16:10:24 <mestery> :) 16:11:08 <Sukhdev> ha ha - funny!! 16:11:23 <rkukura> Please, don't hesitate to speak! 16:11:38 <Sukhdev> what is the acceptable level of coverage? 16:12:13 <mestery> For UT? 16:12:17 <Sukhdev> yes 16:12:40 <rkukura> Sukhdev: Not sure about others, but my view is that meaningful code should be 100% covered, but some error handling code is acceptable to not cover. 16:12:48 <mestery> +1 ^^^^ 16:13:18 <rkukura> Also, things like abstract methods in base classes don't need coverage (not sure if they get reported) 16:13:54 <mestery> Thanks for answering that rkukura. 16:14:00 <mestery> Now, lets get back to binding management. 16:14:23 <mestery> Lets discuss "Original vs. Bound Segment" now. 16:14:49 <mestery> #link https://review.openstack.org/#/c/62380/ WIP around "Original vs. Bound Segment" 16:15:20 <matrohon> this was just a patch to illustarte my words 16:15:30 <matrohon> during the mail discussion 16:15:38 <mestery> matrohon: OK, thanks, I think it moves in the right direction :) 16:15:43 <matrohon> it has to be improved and tested 16:16:10 * mestery nods. 16:17:00 <rkukura> Is the basic idea to make PortContext.original_bound_segment available to MDs in port_update_precommit and port_update_postcommit? 16:17:31 <rcurran> and the delete_port_pre/postcommit()? 16:17:46 <matrohon> rkukura: yes 16:18:47 <rkukura> rcurran: I guess if the unbind is implicit and part of the delete, then it makes sense for this to be visible in the delete calls 16:19:29 <rcurran> that's what i was thinking 16:19:40 <rkukura> I think that would mean that the unbind occurred before the delete transaction, but maybe it should be occuring as part of the transaction (i.e. not happen if the delete TX rolls back) 16:20:48 <rkukura> So this gets to the heart of the original issue - how does unbind relate to port_delete? 16:20:59 <rcurran> i have these same questions. i used matrohon's bug (instead of emails) to get these conversations going 16:21:00 <mestery> Doesn't unbind have to happen BEFORE a delete? 16:21:41 <rkukura> mestery: If it does happen before delete, I think it needs to be port_update from the view of the MDs. 16:22:13 <mestery> rkukura: That makes sense. But would the case be for having it happen AFTER the delete? To me, that doesn't make sense. 16:22:47 <rkukura> In that case, the client does port_delete, the drivers all see port_update for the unbind with bound_segment none and old value in orignal_unbound_segment, and then the drivers all see port_delete with none in both bound_segment and original_bound_segment 16:23:16 <rkukura> I think the other option is that is is part of the delete itself 16:23:16 <mestery> That makes sense as well I think. 16:24:00 <rkukura> But that means that if the delete TX rolls back, the unbind never happened. 16:24:03 <rcurran> right, that's where we left off before the break :-), i could rewrite the cisco nexus md to work to that design 16:24:36 <mestery> rcurran: So you're on board with this approach then? 16:25:09 <rkukura> Do we have any strong arguments for/against either of the two approaches (explcit or implicit)? 16:25:50 <rkukura> rcurran: Not sure which approach you are referring to 16:26:08 <rcurran> your comment from 11:22 16:26:30 <rkukura> I don't have timestamps 16:26:33 <mestery> So explicit. 16:26:34 <rcurran> right now i "unbind/delete" cisco nexus md resources on delete_port 16:26:35 <shivh> I am seeing 2 approches in the above convesation: 1. unbind as part of delete 2. delete can happen only for unbound ports 16:26:42 <shivh> I see #2 to be simple. 16:26:57 <matrohon> the first approach looks better to me, MD could react at bindings update 16:27:31 <rcurran> i can change to update_port_pre/postcommit() as long as i have access to the bound segment info (and know that it's unbinding) 16:27:37 <matrohon> but I don't see any use cases yet :) 16:28:23 <rkukura> I'm a bit concerned about two separate TXs from one API call 16:29:04 <rkukura> If we do the unbind first, with its own port_update_precommit and port_update_postcommit, then do the port_delete_precommit and have to roll back, we've left a mess 16:29:35 <mestery> rkukura: So making it implicit is easier from a DB perspective then? 16:30:23 <rkukura> I think I'm leaning towards implicit, where the unbind is part of the delete TX, and MDs only see port_delete_[pre|post]_commit 16:31:17 <mestery> So then as long as we have hte original bound segment available, will that satisfy your requirements rcurran? 16:31:34 <shivh> I like #1 approach for its elegance. Does holding the transaction for that long going to affect perf. 16:31:58 <rcurran> that would be my question ... just need accessing to the original_bound_segment on delete_port_pre/postcommit() 16:32:04 <rkukura> So then the question is whether the unbind_port call on the bound MD happens before the delete_port_precommit calls on all MDs, or after them but before the delete_port_postcommit calls 16:32:56 <rkukura> shivh: I think we'd make sure no postcommit calls happen during the TX, and MDs would only make remote calls in the postcommit calls 16:34:33 <mestery> I don't understand how we can delete a port before unbinding it, pre or post. I think we need to unbind before we delete it. 16:35:30 <rkukura> mestery: I guess the unbind happens as part of the delete TX, but the MD handles it in the port_delete_postcommit call after that TX. 16:35:56 <shivh> rkukura: worth discussing?: splitting the api and let the app decide to make sure it is unbound before sending delete. 16:36:01 <rkukura> Right now the bind_port() and unbind_port() calls happen inside transactions. 16:36:47 <rkukura> I think our current calling of bind_port() inside the TX is a problem because the MD may need to make a remote call to see if it can bind that port. 16:37:04 <rcurran> which is why, today, delete_port_precommit() has access to the bound_segment, but delete_port_postcommit does not 16:37:06 <matrohon> rkukura : agrre 16:37:07 <mestery> rkukura: I agree with that. 16:39:26 <mestery> OK, so lets circle back here and make sure everyone agrees what we've talked about. 16:39:29 <rkukura> rcurran: We absolutely need to make sure all MDs see which segment has been unbound in a postcommit call, whether that is port_delete_postcommit or port_update_postcommit 16:39:31 <mestery> rkukura: Care to summarize? 16:40:13 <rcurran> rkukura: agreed 16:40:23 <rkukura> What I just said to rcurran is the original issue, but we also need to look at the bind_port() TX issue, and come up with an overall solution 16:41:17 <rkukura> I would be willing to look at how to move bind_port() out of the TX this week, and propose a patch or at least explain the options in email before Monday 16:41:42 <rcurran> great 16:41:46 <mestery> rkukura: That would be awesome! Consider it yours. 16:41:55 <matrohon> when an MD is responsible for the binding it need to ask its external device during the pre call, to be able to wright the decision of the extrernal to the DB, no? 16:42:00 <mestery> #action rkukura Look at moving bind_port() out of the TX and send email or a WIP patch to discuss. 16:42:16 <mestery> matrohon: I think so, yes. That has to happen outside the TX for obvious reasons. 16:42:41 <rkukura> matrohon: right 16:43:36 <rkukura> I'll look at all the things that can trigger binding, unbinding, and rebinding, and see if we can handle those with a minimal number of transactions. 16:44:33 <mestery> Thanks rkukura. 16:44:42 <mestery> Is there anything else to discuss with regards to binding now? 16:45:11 <rkukura> A port_update that changes the host_id is probably the interesting case - not clear if the bind_port on the MD(s) should happen before the port_update_precommit calls 16:45:55 <mestery> I'm not clear on that one either, but some MDs will again need to make remote calls in that case. 16:46:04 <rkukura> maybe the interaction with the MD for bind_port needs two phases, one to check and one to finalize 16:46:35 <mestery> I think that makes sense rkukura. 16:46:51 <rkukura> Should we move this to email or #openstack-neutron? 16:46:59 <matrohon> salv-orlando had some issues with binding too, did he talk to you? 16:47:11 <matrohon> rkukura : it's a good idea 16:47:48 <rkukura> matrohon: Is this the issue that marun has also been raising about the agent liveness and this not being a realtime system? 16:48:14 <rcurran> i prefer email to keep this discussion going 16:48:50 <rkukura> rcurran: OK, I will send an email with a proposal or set of options ASAP 16:48:58 <rcurran> thanks 16:49:47 <matrohon> rkukura : https://bugs.launchpad.net/neutron/+bug/1253896 16:50:36 <matrohon> rkukura : https://bugs.launchpad.net/neutron/+bug/1253896/comments/30 16:51:53 <rkukura> matrohon: thanks 16:52:06 <mestery> OK, rkukura will continue this discussion on the ML now. 16:52:12 <mestery> We have 8 minutes left. 16:52:19 <mestery> I wanted to cover one more thing and leave open discussion. 16:52:22 <mestery> #topic Bugs 16:52:26 <mestery> I listed some bugs in the agenda. 16:52:41 <mestery> Please have a look at those, it would be good to try to review those ones this week. 16:53:07 <mestery> If there are other ML2 related bugs not there, please add them to that agenda or ping rkukura or myself for core reviews. 16:53:14 <mestery> #topic Open Discussion 16:53:23 <shivh> mestery, rkukura: need your review cycles for https://review.openstack.org/#/c/60129 16:53:39 <mestery> shivh: Will definitely take a peek at this one! 16:53:43 <rkukura> Lets not drop the ball on the TypeDriver refactoring that opens up the set of provider attributes 16:53:54 <shivh> thanks. need to progress for tempest with this... 16:54:14 <rkukura> shivh: I'll look at that 16:54:47 <shivh> rkukura, mestery: thanks 16:55:13 <mestery> rkukura: Good call! Do you have that link handy by any chance? 16:55:17 <asadoughi> re:blueprint ovs-firewall-driver, status update: continuing to make progress on existing reviews and working on items that will further agent before getting to the "meat" of the firewall 16:55:48 <mestery> asadoughi: Thanks for the update! 16:56:01 <doude_> What about the sumit discussion https://docs.google.com/document/d/1ZHb2zzPmkSOpM6PR8M9sx2SJOJPHblaP5eVXHr5zOFg/edit ? 16:56:04 <rkukura> Has anyone been tracking the SRIOV / PCI-passthru work from an ML2 perspective? 16:56:13 <doude_> RPC handling in ML2 for Type and Mechanism Drivers 16:56:35 <rkukura> doude_: Do we have a BP for this? 16:56:49 <mestery> rkukura: Regarding PCI-passthru, I've been in touch with ijw and some Cisco folks working on that. 16:56:58 <mestery> rkukura: We should attend their meeting next week on IRC and bring that up perhaps. 16:57:08 <rkukura> mestery: +1 16:57:10 * ijw wavs 16:57:10 <doude_> I don't find bp for that, I don't remember who initiate it 16:57:23 * mestery has now unleashed ijw with 3 minutes left in this ML2 meeting. 16:57:35 <doude_> the gdocs is owned by Arvind Somya 16:57:36 <mestery> I think asomya did that Google Doc if I'm not mistaken. 16:57:51 <mestery> doude_: I'll ping asomya on that one and see where he's at with it, there is no BP right now. 16:57:56 <ijw> So yes - we know in theory what we want to do in the plugin but I don't know we have the skillset to write one. Happy to discuss with anyone who's interested. 16:58:11 <mestery> #action mestery to ping asomya around https://docs.google.com/document/d/1ZHb2zzPmkSOpM6PR8M9sx2SJOJPHblaP5eVXHr5zOFg/edit 16:58:36 <asadoughi> ijw: who is we and what are you takling about? 16:58:38 <mestery> ijw: rkukura and I will join the passthrough meeting next week and bring up ML2 issues there. 16:58:56 <ijw> PCI group - me, baoli, irenab, heyongli 16:58:56 <asadoughi> ijw: nevermind 16:58:58 <doude_> mestery: ok, thanks. I plan to do some work in ML2 which need to use thaht 16:59:02 <rkukura> ijw: I'll try to catch up on the PCI email thread beforehand 16:59:16 <mestery> OK, we're reaching the end of time now everyone. 16:59:19 <ijw> Next passthrough meeting is tomorrow 1300CET #openstack-meeting-alt, I think 16:59:30 <mestery> Lets continue discussions on ML or in-channel. 16:59:33 <rkukura> ijw: thanks! 16:59:43 <mestery> And we'll see you all next week, same IRC-time, same IRC-channel. :) 16:59:44 <mestery> #endmeeting