14:00:12 <mestery> #startmeeting networking_ml2
14:00:13 <openstack> Meeting started Wed Jun 19 14:00:12 2013 UTC.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:16 <openstack> The meeting name has been set to 'networking_ml2'
14:00:27 <mestery> #agenda https://wiki.openstack.org/wiki/Meetings/ML2
14:00:42 <mestery> Before we get started on the agenda, rkukura, you here too?
14:00:53 <rkukura> hi
14:01:07 <mestery> hey
14:01:38 <mestery> OK, so the first item on the agenda is blueprints.
14:01:46 <mestery> Lets start with the MechanismDriver blueprint
14:02:00 <mestery> #link MechanismDriver Code Review https://review.openstack.org/33201
14:02:18 <mestery> apech: Nice work on getting this out over the weekend!
14:02:29 <apech> sure - got a lot of great comments, thanks everyone. I think i'm in line with most of them. Had one question on testing that might be interesting
14:02:43 <apech> i should have another version out for review in the next day or so
14:03:08 <mestery> apech: great!
14:03:15 <mestery> apech: What was the testing question?
14:03:32 <apech> mark mcclain rightly brought up the question of testing, which I had been a bit ignoring under the assumption that most would be driven by the actual mechanism driver implementations (including ours)
14:03:49 <apech> any thoughts on a generic test suite I should add, or is putting this off in the short term ok?
14:04:06 <apech> I could go down the path of adding test mechanism drivers, but that seemed a bit silly
14:04:17 <mestery> I think putting it off for the short term is ok, until we get an actual MechanismDriver.
14:04:24 <rkukura> An obvious approach would be to unit test the manager classes using a mock driver
14:04:49 <rcurran> i'm guessing that's what mark m was looking for
14:04:52 <apech> sure, that's true, could right a targetted test for the manager
14:05:01 <apech> okay, thanks!
14:05:11 <apech> other people have questinos for me on the mechanism driver?
14:05:15 <mestery> Yes, I think in general, we'll want solid unit tests before most of these blueprints go up.
14:05:20 <rkukura> we probably should also plan a test for each driver class too
14:05:30 <apech> rkukura - yes, for sure
14:06:16 <rkukura> I was also trying to figure out how to test the rpc methods to make sure correct results returned, etc.
14:06:50 <sukhdev> ON the subject od testing, Can I ask you guys a question about bringing up of ML2 with devstack?
14:06:55 <apech> rkukura: are you thinking of an end to end test, or a stubbed out rpc responder?
14:07:14 <rkukura> apech: had not decided between those
14:07:27 <rkukura> sukhdev: what's the devstack question?
14:07:51 <apech> rkukura: yeah, this comes up in the context of all mechanism drivers making external calls, though there I think the response has to be stubbed out
14:08:07 <mestery> apech: Agreed.
14:08:22 <rcurran> yes, that's what we did w/ our netconf calls ... stubbed
14:08:37 <sukhdev> rkukura: yesterday I was able to play with ML2, created networks, VMs, etc... but, had to struggle a lot - could not find any instructions on config
14:08:44 <rkukura> would seem to make sense to test mechanism drivers that make remote calls directly, with a stubbed out client lib or whatever
14:09:21 <sukhdev> Is it documented some where as to the localrc setups to fire off ML2 instead of OVSPlugin?
14:09:59 <rkukura> sukhdev: we will definitely need to cover ml2 in the docs, etc., but maybe a wiki page for now that everyone can easily contribute to
14:10:52 <rkukura> sukhdev: The comments in the script for devstack's ml2 support should have some info
14:11:03 <sukhdev> rkukura: do you have any wiki page - where I can add to? or do you have any cheatsheet that you have been using that I can leverage from?
14:11:18 <mestery> #action mestery to setup a wiki page for ML2 with devstack
14:11:30 <mestery> sukhdev: I'll set one up (or start one).
14:11:51 <sukhdev> mestery: tahnks
14:11:58 <rkukura> lets have one top-level ml2 page with links to a devstack page, the meeting page, etc.
14:12:08 <mestery> rkukura: OK, makes sense.
14:12:14 <mestery> OK, any more questions on MechanismDriver?
14:12:42 <rkukura> Did I post my comment about bulk operations?
14:12:44 <apech> mestery: i'm good
14:12:53 <mestery> rkukura: I don't think so.
14:12:54 <apech> rkukura: yes
14:13:02 <rcurran> not for now, i'm porting over one of our subplugins now ... conf questions will need to be addressed (obviously)
14:13:06 <apech> sorry, i meant in the review :)
14:13:16 <mestery> apech: No worries.
14:13:26 <mestery> rcurran: Yes, configuration items will have to be dealt with.
14:13:49 <mestery> OK, lets move on to the next agenda item.
14:13:54 <rkukura> Do we all agree its OK to use the default bulk operation implementations for now that call the normal ones inside a single transaction?
14:14:02 <apech> rkukura: did you have something you wanted to bring up here?
14:14:21 <mestery> rkukura: I'm all in favor of keeping things simple, given how close H2 is. :)
14:14:26 <apech> rkukura: that seems like the simple approach
14:15:05 <apech> rkurura: do you think the api will have to change to better support bulk operations?
14:15:07 <rkukura> agreed - just want to make sure we are clear that the outside-the-transaction semantics for the _postcommit() ops don't apply yet to bulk ops
14:15:34 <mestery> I think that's a tradeoff I'm ok with for now.
14:15:40 <apech> rkukura: ah right, good point
14:15:58 <apech> mestery: agreed, let's get a first working version we're happy with
14:16:20 <rkukura> I think the proposed mechanism driver API should be OK, but we will eventually need to call create_precommit() for all the items, commit, then call create_postcommit() for each
14:16:38 <mestery> #info ML2 MechanismDriver to keep default bulk operations for now due to the approach of H2.
14:16:47 <apech> rkukura: right, we'll need to override the _bulk functions as you pointed out in the review
14:17:03 <rkukura> lets file a  bug to track this
14:17:07 <apech> I'm happy to take that on for H3
14:17:17 <mestery> apech: Can you file a bug?
14:17:24 <apech> mestery: sure, will do
14:17:50 <mestery> #action apech to file bug to track bulk operation fixes for H3.
14:18:05 <rkukura> sounds good
14:18:08 <mestery> OK, anything else on MechanismDriver?
14:18:32 <mestery> #topic ml2-portbinding
14:18:40 <mestery> I thought I'd move to portbinding next.
14:18:44 <mestery> Before moving to the TypeDrivers.
14:18:49 <rkukura> any feedback on the "context" class idea, which might apply to portbinding and other ops on mechanism driver?
14:19:09 <apech> rkukura: I like it (especially the caching)
14:19:27 <mestery> rkukura: Do you have a link to info on that?
14:19:29 <apech> one question is how far to go - do you put everything in the context, or is 'network' / 'port' dict still separate
14:19:32 <apech> am coding it up now :)
14:19:51 <mestery> apech: got it :)
14:19:57 <sukhdev> I think we need info on the instance information in the context
14:20:09 <rkukura> cool - what are your thoughts on making it the only param?
14:20:58 <apech> standard thoughts on type safety. Were you thinking of a single context class, or one for network, one for port, etc
14:21:05 <rkukura> and do we want separate context classes for each operation, for each resource type, or a single one?
14:21:20 <apech> rkukura: I was thinking separate per resource
14:21:29 <rkukura> makes sense if it works
14:21:33 <apech> thoughts?
14:21:39 <rkukura> could always subclass for specific ops later if needed
14:21:59 <apech> right, was definitely going to go heirarchical. hard to saw how it will turn out not having finished it yet
14:22:36 <rkukura> OK, as soon as you settle on something, please share it and I'll try to figure out if the portbinding stuff fits
14:22:42 <sukhdev> folks, we need Instance info, in addition to port info -
14:22:45 <apech> okay that works
14:22:49 <apech> others okay with the context idea?
14:23:01 <rkukura> sukhdev: what do you mean by "instance info"?
14:23:11 <mestery> apech: Seems like it will work to me.
14:23:23 <sukhdev> rkukura: VM Id, etc
14:23:35 <rcurran> not following the portbinding stuff specifically, but everything regarding the use of context makes sense to me
14:23:50 <apech> rcurran: great
14:23:56 <apech> rkukura: will send out review once I have it
14:24:07 <rkukura> sukhdev: the portbinding ops on mech drivers will have the host_id from the portbinding extension, but I'm not sure about more specific info from nova
14:25:02 <sukhdev> rkukura: Yes, I know it has host_id - but, we need in addition VM ID, name, etc. -- some additional params
14:25:26 <rkukura> rcurran: the portbinding BP covers letting the MechanismDrivers determine what segment will be used for a port, and returning the correct binding:vif_type for the mechanism used on that node
14:25:58 <rcurran> ok, got it
14:26:06 <rkukura> sukhdev: does the necessary info get set on port currently - device_id or something?
14:26:46 <sukhdev> rkukura: I can look it up and let you know - as of now, I do not know
14:27:44 <rkukura> sukhdev: OK - I think the port dict will be available to mech drivers, so if they should be able to get the instance ID for the port and get the nova instance
14:28:37 <mestery> OK, anything else on portbinding?
14:28:58 <rkukura> hopefully will have code to look at early next week
14:29:10 <mestery> rkukura: Great!
14:29:29 <mestery> OK, if nothing else on portbinding, lets move on to the next agenda item then.
14:29:53 <mestery> #topic ml2-gre
14:30:01 <mestery> #link https://review.openstack.org/33297 ml2-gre code review
14:30:04 <matrohon> hi
14:30:11 <mestery> matrohon: Hi!
14:30:19 <matrohon> i just submitted a new patch
14:30:23 <matrohon> on the review
14:30:51 <mestery> matrohon: This one looks like it has a new TunnelType class now?
14:31:03 <rkukura> matrohon: I'll give that a close review today
14:31:33 <matrohon> mestery : yes, t's a generic clss to handle RPC and endpoints stuff related to tunnel types
14:31:54 <mestery> matrohon: Great! Thanks for taking care of this, as the VXLAN type driver will need this as well.
14:32:35 <mestery> I will also review this today, though I see it is failing Jenkins right now.
14:32:58 <mestery> matrohon: Looks like the white space issues may be causing flake8 to fail.
14:33:19 <matrohon> yes i wanted to share it for the moment, so i misse flake8 tests
14:33:49 <mestery> OK, so any questions on ml2-gre?
14:33:51 <rkukura> should we ignore the jenkins flake8 issue for now, and review this version
14:34:09 <matrohon> rkukura : yes please, i've put it in WIP
14:34:14 <rkukura> ok
14:34:36 <matrohon> please telle what what do you think about the general architecture
14:34:50 <rkukura> will do - makes sense so far
14:34:56 <mestery> matrohon: Sounds good.
14:34:58 <matrohon> thanks
14:35:36 <mestery> Any more questions on ml2-gre before we move to the next agenda item?
14:36:18 <mestery> #topic ml2-vxlan
14:36:35 <mestery> So, the updates on ml2-vxlan are short: I haven't started coding this yet.
14:36:35 <mestery> I'
14:36:44 <mestery> I've been stuck on a bug (which we'll discuss next).
14:36:56 <mestery> matrohon: The work you've done for ml2-gre will make ml2-vxlan easier, however.
14:37:18 <matrohon> mestery : hope so
14:37:41 <matrohon> the real challenge will be to manage both vxlan and gre on OVS
14:38:04 <mestery> matrohon: Yes, that will require some agent changes, which I will try to make as part of the ml2-vxlan blueprint I think.
14:38:18 <feleouet> mestery: one question about that
14:38:36 <feleouet> I gave a look at https://review.openstack.org/#/c/33107/
14:39:17 <feleouet> and am wondering on how to avoid duplicate work, as we were willing to start working on l2-population
14:39:38 <mestery> feleouet: I have a new version of that patch I have not submitted yet, as I'm blocked on testing due to some Nova bug right now.
14:39:55 <mestery> feleouet: I can submit what I have now (it passes flake8 and unit tests) so you can review the latest version.
14:40:19 <mestery> I think the l2-population work is intertwined with this as you say.
14:40:30 <feleouet> which nova bug?
14:41:06 <mestery> feleouet: I need to search for it, what I see is with the latest Havana, when I launch VMs nova-compute stops working (e.g. nova-manage service list shows it dead).
14:41:23 <mestery> Something is hanging somewhere, as even the quantum agents stop communiating back to the server.
14:41:30 <mestery> This is on Fedora 18 (rkukura, have you seen this recently?)
14:42:03 <rkukura> mestery: no, but I haven't run devstack for a couple weeks
14:42:25 <mestery> rkukura: If you give it a shot with Fedora, let me know if things work for you.
14:42:38 <mestery> Anyways, I need to chase that down after the meeting this morning.
14:42:39 <rkukura> ok
14:43:05 <mestery> feleouet: Sorry for the long-winded story there, but how should we ensure no overlap?
14:44:45 <feleouet> mestery: don't know how to manage that, but we're goig to start working on that on our side
14:45:11 <mestery> feleouet: OK, lets try to stay in sync. I'll send my latest patch out after the meeting, please provide comments if you can.
14:45:25 <matrohon> mestery : great
14:45:29 <feleouet> maybe ovs agent can stay as is (meaning ovs or vxlan) in the meanwhile
14:45:46 <feleouet> or we'll rebase our efforts on your work
14:45:50 <mestery> feleouet: That's the plan, at least with the bug you referenced.
14:46:00 <mestery> feleouet: OK, great!
14:46:24 <mestery> OK, I think we covered the ML2 Bugs during this last discussion.
14:46:32 <mestery> So, lets move on to the next agenda item then.
14:46:44 <mestery> #topic Ported MechanismDrivers
14:47:00 <mestery> I put a list of the MechanismDrivers I know are under development in the agenda.
14:47:12 <mestery> If people want to update status during this slot, that would be great!
14:47:55 <sukhdev> We will be submitting Arista Driver sometime next week to be added to this list
14:48:19 <mestery> sukhdev: Cool!
14:48:38 <rcurran> cisco - porting over nexus plugin (assuming OVS will still be hardcoded for now ... although this still needs to be addressed)
14:48:53 <mestery> rcurran: Great!
14:48:56 <rcurran> for other cisco subplugins to be ported over
14:49:51 <mestery> For the OpenDaylight driver, I need to port that over as a MechanismDriver. I won't get started on that until next week I suspect.
14:50:24 <mestery> #topic Questions/Comments?
14:50:31 <mestery> OK, anything else for ML2 this week?
14:51:09 <rkukura> mestery: great job with the meetings! thanks
14:51:12 <rkukura> !
14:51:18 <mestery> rkukura: Thanks!
14:51:32 <mestery> OK, thanks for everyone's efforts on all the ML2 work!
14:51:39 <apech> thanks all
14:51:42 <mestery> Lets keep the momentum going as H2 approaches!
14:51:47 <mestery> #endmeeting