22:02:08 <danwent> #startmeeting 22:02:09 <openstack> Meeting started Tue Jun 14 22:02:08 2011 UTC. The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:02:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic. 22:02:11 <ryu_ishimoto> i'm here 22:02:18 <danwent> anyone we need to wait for? 22:02:38 <danwent> (i.e., does anyone know of someone who is coming for sure but is not here yet?) 22:03:01 <bmcconne> troy will likely turn back to his monitor at some point :) 22:03:14 <danwent> #topic project status 22:03:43 <danwent> #info dendrobates is beginning the process of applying for netstack to be an openstack incubation project 22:04:15 <SumitNaiksatam> Hello! 22:04:19 <danwent> I believe most of you saw this email, but we also switched from https://blueprints.launchpad.net/network-service to https://launchpad.net/quantum for quantum specific code 22:04:24 <ecarlin> hello 22:04:37 <danwent> if you have branches or bugs that are quantum specific, please move them to quantum. 22:05:10 <danwent> I also see melange code on the network-service page. Troy, what is the long term plan for where this repo will live? 22:05:39 <danwent> (anyone at rackspace that is close enough to kick troy? :P) 22:05:42 <bmcconne> just got his attention 22:06:28 <danwent> ok, we'll come back to that. 22:06:41 <danwent> #topic quantum update 22:07:01 <danwent> we're continuing to do testing and bug finding on quantum. 22:07:08 <troytoman> just caught up. we are working on a plan to have melange live within the Nova project. it looks like we can make that work 22:07:28 <danwent> troytoman: great, thanks. so eventually the branches in network-service will go away? (no rush) 22:08:05 <troytoman> yes. there are some issues with where the code lives and how we tie together running tests etc. I expect that will be settled within the week. 22:08:14 <troytoman> then it will move out of network service 22:08:24 <danwent> k, great 22:08:30 <danwent> on quantum: we're will have a plugin that works with KVM soon, though it may require a tweaked version of nova 22:08:52 <danwent> we're turning our focus more to how quantum will work with nova + melange. 22:09:04 <danwent> on the topic of nova, ryu, can you provide an update on the nova refactoring? 22:09:42 <danwent> (or anyone from midokura?) 22:10:03 <midodan> hi there 22:10:14 <midodan> i'll try to kick Ryu awake 22:10:22 <danwent> ah, i thought I saw him join just a bit ago 22:10:32 <ryu_ishimoto> yup i'm here, sorry 22:10:37 <jlm^> He is on channel. 22:10:42 <midodan> :) 22:10:59 <danwent> ryu, can you give a quick update? 22:11:18 <danwent> particularly with respect to the vif-plugging side of things. We've had a couple questions on that from folks at Cisco as well. 22:11:44 <ryu_ishimoto> sure, that's also where we are struggling a bit with 22:11:57 <ryu_ishimoto> VIsh is here this week in Japan and we have been discussing how we should implmeent that part 22:12:21 <SumitNaiksatam> is this discussion being captured/documented somewhere? 22:12:22 <danwent> Ok. would be great to see a BP, so we can provide feedback. 22:13:02 <midodan> yes, i agree. there have been several conversations about this issue going on in separate forums. we will write a doc and get some feedback. 22:13:22 <danwent> Great, thanks. There's a lot of interest particularly around the flexibility of generating <interface> config for libvirt... 22:13:23 <SumitNaiksatam> much appreciated...as with everything else, sooner would be better :-) 22:13:45 <danwent> Ok, anything else on quantum? 22:13:46 <SumitNaiksatam> at least at a high level as to where the discussion is heading... 22:14:05 <midodan> danwent: you mentioned that there would soon be a version running with KVM 22:14:45 <midodan> how will that work? with libvirt? do you have a doc describing it? 22:14:47 <danwent> midodan: the quantum service will be the same regardless, I more meant that at least the OVS plugin will be able to work with KVM (this is really more of a libvirt thing) 22:15:02 <midodan> right right, that's the part i was wondering about, the ovs plugin 22:15:08 <danwent> This will require changes to nova in the vif-plugging area, which is what we were asking about. 22:15:36 <midodan> ok, we should have a discussion offline, perhaps later today, to sync up 22:15:47 <danwent> Code will be up. At a high-level, its just using type="ethernet" instead of type="bridge" and making a couple ovs commands for setup/teardown 22:16:08 <danwent> Its just a hack now, to demonstrate the flexibility we would need from the nova refactoring of libvirt. 22:16:16 <ryu_ishimoto> danwent: right, that's how we implemented in our branch 22:16:19 <danwent> and to let people play with quantum with a single server KVM setup. 22:16:30 <danwent> ryu: yes, exactly 22:16:47 <midodan> ok, sounds good, thanks. 22:16:56 <ryu_ishimoto> danwent: ok let's keep the discussion going offline then. 22:17:03 <danwent> ryu: when you mention a branch, are you referring to the original branch discussed at the summit? 22:17:19 <ryu_ishimoto> danwent: no, the new branch, the one that's less disruptive 22:17:37 <ryu_ishimoto> danwent: lp:~/midokura/nova/network-refactoring 22:17:51 <danwent> ryu: great, thanks. 22:18:00 <danwent> ok, anything else on quantum? 22:18:02 <ryu_ishimoto> but the old branch does the same thing in regards to libvirt interfaces 22:18:11 <RamD> kvm related is of our interest too. 22:18:40 <salv-orlando> on quantum API: I have implemented the changes proposed in last week's email 22:19:03 <danwent> RamD: yup. you may want to do a similar hack with libvirt + the type="direct" to demonstrate the flexibility that you need, as I'm not sure the existing refactoring changes are sufficient. 22:19:20 <danwent> salv: can you quickly describe them? 22:19:39 <salv-orlando> 1) removing orchestration operation for PUT attachment 22:19:48 <danwent> ah, yes. now I remember. thanks. 22:19:55 <salv-orlando> 2) using detail action for retrieving list of resources attached to network 22:20:27 <danwent> Ok, does anyone want to give an update on melange or donabe? 22:20:29 <salv-orlando> changes are in a branch I'm using to fix a couple of bugs I spotted as well. Will propose for merge into trunk ASAP 22:20:45 <danwent> salv: awesome, great. 22:21:08 <salv-orlando> before moving to other projects, did we reach a consensus on the semantics of the attach operation? 22:21:29 <salv-orlando> I remember it was discussed two weeks ago, but I don't know whether we decided something 22:21:56 <danwent> I believe the semantics are basically of plugging a cable, or was there a more specific point that the discussion was focused on? 22:22:38 <salv-orlando> Sumit (if I'm not wrong) was proposing to remove the operation as it was beyond the scope of the quantum service 22:23:02 <salv-orlando> basically If I remember it correctly, it was responsibility of the compute node to "plug the cable" 22:23:24 <SumitNaiksatam> Salv: not I wasn't 22:23:25 <danwent> ah, i think the distinction here is a "logical plug" vs. the "hypervisor plug". 22:23:32 <salv-orlando> rigth 22:23:43 <danwent> I think we're clear on that now. 22:23:48 <danwent> Sumit? 22:24:04 <SumitNaiksatam> Yeah, I guess based on the discussion we had the other day 22:24:20 <danwent> Yup, we'll need to focus on the vif-plugging work in nova for that. 22:24:31 <salv-orlando> sweet, just wanted to make sure of that 22:24:38 <SumitNaiksatam> agreed 22:24:42 <danwent> salv: yes, thanks for bringing it up. 22:24:48 <danwent> #topic: open discussion 22:25:28 <danwent> speak now or hold you peace until next week :) 22:25:46 <danwent> #endmeeting