22:02:08 #startmeeting 22:02:09 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 22:02:11 i'm here 22:02:18 anyone we need to wait for? 22:02:38 (i.e., does anyone know of someone who is coming for sure but is not here yet?) 22:03:01 troy will likely turn back to his monitor at some point :) 22:03:14 #topic project status 22:03:43 #info dendrobates is beginning the process of applying for netstack to be an openstack incubation project 22:04:15 Hello! 22:04:19 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 hello 22:04:37 if you have branches or bugs that are quantum specific, please move them to quantum. 22:05:10 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 (anyone at rackspace that is close enough to kick troy? :P) 22:05:42 just got his attention 22:06:28 ok, we'll come back to that. 22:06:41 #topic quantum update 22:07:01 we're continuing to do testing and bug finding on quantum. 22:07:08 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 troytoman: great, thanks. so eventually the branches in network-service will go away? (no rush) 22:08:05 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 then it will move out of network service 22:08:24 k, great 22:08:30 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 we're turning our focus more to how quantum will work with nova + melange. 22:09:04 on the topic of nova, ryu, can you provide an update on the nova refactoring? 22:09:42 (or anyone from midokura?) 22:10:03 hi there 22:10:14 i'll try to kick Ryu awake 22:10:22 ah, i thought I saw him join just a bit ago 22:10:32 yup i'm here, sorry 22:10:37 He is on channel. 22:10:42 :) 22:10:59 ryu, can you give a quick update? 22:11:18 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 sure, that's also where we are struggling a bit with 22:11:57 VIsh is here this week in Japan and we have been discussing how we should implmeent that part 22:12:21 is this discussion being captured/documented somewhere? 22:12:22 Ok. would be great to see a BP, so we can provide feedback. 22:13:02 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 Great, thanks. There's a lot of interest particularly around the flexibility of generating config for libvirt... 22:13:23 much appreciated...as with everything else, sooner would be better :-) 22:13:45 Ok, anything else on quantum? 22:13:46 at least at a high level as to where the discussion is heading... 22:14:05 danwent: you mentioned that there would soon be a version running with KVM 22:14:45 how will that work? with libvirt? do you have a doc describing it? 22:14:47 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 right right, that's the part i was wondering about, the ovs plugin 22:15:08 This will require changes to nova in the vif-plugging area, which is what we were asking about. 22:15:36 ok, we should have a discussion offline, perhaps later today, to sync up 22:15:47 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 Its just a hack now, to demonstrate the flexibility we would need from the nova refactoring of libvirt. 22:16:16 danwent: right, that's how we implemented in our branch 22:16:19 and to let people play with quantum with a single server KVM setup. 22:16:30 ryu: yes, exactly 22:16:47 ok, sounds good, thanks. 22:16:56 danwent: ok let's keep the discussion going offline then. 22:17:03 ryu: when you mention a branch, are you referring to the original branch discussed at the summit? 22:17:19 danwent: no, the new branch, the one that's less disruptive 22:17:37 danwent: lp:~/midokura/nova/network-refactoring 22:17:51 ryu: great, thanks. 22:18:00 ok, anything else on quantum? 22:18:02 but the old branch does the same thing in regards to libvirt interfaces 22:18:11 kvm related is of our interest too. 22:18:40 on quantum API: I have implemented the changes proposed in last week's email 22:19:03 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 salv: can you quickly describe them? 22:19:39 1) removing orchestration operation for PUT attachment 22:19:48 ah, yes. now I remember. thanks. 22:19:55 2) using detail action for retrieving list of resources attached to network 22:20:27 Ok, does anyone want to give an update on melange or donabe? 22:20:29 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 salv: awesome, great. 22:21:08 before moving to other projects, did we reach a consensus on the semantics of the attach operation? 22:21:29 I remember it was discussed two weeks ago, but I don't know whether we decided something 22:21:56 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 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 basically If I remember it correctly, it was responsibility of the compute node to "plug the cable" 22:23:24 Salv: not I wasn't 22:23:25 ah, i think the distinction here is a "logical plug" vs. the "hypervisor plug". 22:23:32 rigth 22:23:43 I think we're clear on that now. 22:23:48 Sumit? 22:24:04 Yeah, I guess based on the discussion we had the other day 22:24:20 Yup, we'll need to focus on the vif-plugging work in nova for that. 22:24:31 sweet, just wanted to make sure of that 22:24:38 agreed 22:24:42 salv: yes, thanks for bringing it up. 22:24:48 #topic: open discussion 22:25:28 speak now or hold you peace until next week :) 22:25:46 #endmeeting