15:00:39 <johnthetubaguy> #startmeeting XenAPI 15:00:40 <openstack> Meeting started Wed Sep 25 15:00:39 2013 UTC and is due to finish in 60 minutes. The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:43 <openstack> The meeting name has been set to 'xenapi' 15:00:44 <johnthetubaguy> hello all 15:00:50 <johnthetubaguy> hands up the for XenAPI meeting? 15:00:55 <BobBall> o/ 15:01:51 <matel> hi 15:02:12 <BobBall> euanh is also here 15:02:26 <johnthetubaguy> #topic blueprints 15:02:47 <johnthetubaguy> hey, so any updates on drafting stuff for Icehouse, and filling out the XenAPI session, or other summit sessions? 15:03:13 <BobBall> nope - we've got a brainstorm tomorrow I hope (need to plan it) to see if we want to submit other summit session 15:03:19 <BobBall> or whether then xenapi stuff can fit in the xenapi session 15:03:31 <BobBall> I did say before that we needed to have a chat about the xenapi session 15:03:41 <BobBall> but I can't "fill it out" until there is an etherpad or something that I can contribute to 15:04:03 <johnthetubaguy> sure, I thought we said discuss it this week 15:04:04 <BobBall> and as for drafting stuff for icehouse, still focused on what needs to be done pre-summit ATM 15:04:09 <BobBall> fine by me :) 15:04:25 <matel> Let's start to throw in ideas. 15:04:31 <BobBall> although I'm not in the right mental state to remember the things I wanted to raise today! 15:04:35 <johnthetubaguy> https://etherpad.openstack.org/IcehouseXenAPIRoadmap 15:05:01 <matel> Let's re-visit the previous summit's roadmap first 15:05:44 <matel> compute driver events 15:06:06 <matel> https://blueprints.launchpad.net/nova/+spec/compute-driver-events 15:06:08 <johnthetubaguy> well, sounds like Bob wan't to do this next week 15:06:14 <BobBall> that's still something that we want to do 15:06:25 <BobBall> so hopefully we can get it done in icehouse 15:06:34 <matel> Okay, Let's put it there. 15:06:36 <BobBall> the problem is I can imagine it's lower priority than some of the other things we might be doing 15:06:49 <matel> Also I don't quite get its status from the blueprint. 15:07:51 <BobBall> that blueprint was the KVM version 15:07:56 <BobBall> we don't haev a XenAPI equivalent 15:08:12 <johnthetubaguy> we did have 15:08:16 <johnthetubaguy> but it got dropped 15:08:26 <BobBall> oh right 15:08:31 <BobBall> what's the link to that? 15:08:34 <matel> Okay, so that's one 15:08:37 <BobBall> so we can use that instead of the KVM blueprint as the ref? 15:08:43 <matel> https://blueprints.launchpad.net/nova/+spec/compute-driver-events 15:08:52 <johnthetubaguy> https://blueprints.launchpad.net/nova/+spec/xenapi-compute-driver-events 15:08:56 <matel> look at the dependency tree 15:09:08 <BobBall> duh - didn't scroll down, sorry. 15:09:11 <matel> Okay, we have one. 15:09:13 <BobBall> yup, so that should be on the roadmap 15:10:05 <matel> Who is editing the etherpad now? 15:10:09 <BobBall> me 15:10:31 <BobBall> I'm done though 15:10:33 <BobBall> for now 15:10:34 <matel> volume drivers 15:10:46 <BobBall> more details? 15:10:49 <matel> Should be an easy one. 15:10:57 <matel> A refactor mainly 15:11:10 <matel> So that you can plug in your volume driver to nova. 15:11:54 <BobBall> which volume driver? 15:12:00 <BobBall> maybe I'm being silly but I'm confused :) 15:12:21 <matel> The code that connects a volume to your hypervisor. 15:12:24 <johnthetubaguy> its the cinder stuff 15:12:28 <BobBall> yes 15:12:36 <johnthetubaguy> refactoring to match the libvirt code 15:12:45 <johnthetubaguy> so its easier to plug in additional stuff 15:12:50 <BobBall> a volume being provided by Cinder, using iSCSI? or are you talking about using a different XS SR? 15:13:15 <BobBall> perhaps it's the "additional stuff" that I'm not understanding :) 15:13:17 <matel> For example, say XS supports ceph 15:13:21 <johnthetubaguy> so whatever, you could lay a file SR over the top of some additional thing you attach, etc 15:13:23 <BobBall> ok 15:13:29 <matel> We would need a driver for that 15:13:41 <matel> In a nice separated class. 15:13:46 <johnthetubaguy> yup, ceph is the perfect example 15:13:51 <matel> you just drop it in, and off you go. 15:13:52 <BobBall> okies, understood 15:14:14 <BobBall> I guess that's medium priority for us 15:14:18 <matel> Okay, so that's something we want to do (this example is showing one usecase) 15:14:30 <matel> Okay, put medium to it for now. 15:14:32 <matel> next item. 15:14:43 <matel> gpu passthrough 15:14:55 <matel> https://blueprints.launchpad.net/nova/+spec/xenapi-gpu-passthrough 15:15:14 <johnthetubaguy> I think the priorities mean something different now 15:15:17 <BobBall> I'd say that's medium 15:15:21 <johnthetubaguy> russell will change those 15:15:25 <BobBall> sure 15:15:33 <BobBall> I'm talking about my/our priorities 15:15:36 <matel> I'd say, let's collect some random stuff for now. 15:15:37 <johnthetubaguy> we just need to communicate how important or not it is 15:15:38 <BobBall> as in Citrix 15:15:43 <johnthetubaguy> OK 15:15:46 <BobBall> as an input into the prioritsation of what we want to work on 15:15:54 <BobBall> OFC I expect RS to have their own priorities to feed into this 15:15:57 <johnthetubaguy> well did you want to do that, and come back with your list of ideas? 15:15:58 <matel> it's just a string. 15:16:11 <BobBall> which may influence what citrix implement etc 15:16:33 <johnthetubaguy> yep, I have a meeting on monday to chat about RS summit priorities 15:16:34 <BobBall> *confused* 15:16:37 <BobBall> great 15:16:58 <BobBall> I would very much love that to include input into the XenAPI roadmap 15:17:02 <matel> So, should we carry on with the gpu stuff? 15:17:02 <johnthetubaguy> Just thinking, better use of time, you can discuss at Citrix your prioirty list, then we can review it 15:17:07 <BobBall> yes 15:17:22 <BobBall> vGPU mate? or pci pass through? 15:17:35 <matel> https://blueprints.launchpad.net/nova/+spec/xenapi-gpu-passthrough 15:18:01 <johnthetubaguy> just to clarify, I see the XenAPI roadmap as what we agree at the summit, its not something we present as such 15:18:07 <BobBall> I think it's still very useful (although should be generic PCI pass through support on Xen) and only a little work 15:18:22 <BobBall> understood and agreed John - but I wanted to get lots down to discuss 15:18:31 <BobBall> perhaps the C priorities should be left out for now, yes 15:18:50 <johnthetubaguy> well, feel free to add some of those? 15:18:59 <BobBall> I'll add them to the etherpad yes 15:20:05 <johnthetubaguy> cool, so any more for blueprint / summit discussions? 15:20:22 <matel> Okay, so as John said, we should discuss these things at the summit, so let's collect ideas on etherpad. 15:20:23 <BobBall> do we want to go through the rest of the etherpad or just add actions to update it for next meeting? 15:20:38 <matel> Just an action. 15:20:56 <BobBall> ok 15:21:09 <matel> It doesn't make sense to discuss things now, and just present at the summit, as j said. 15:21:46 <matel> I guess we just need to make sure, we collect stuff on ether, and everyone understands what those things mean. 15:21:49 <BobBall> perhaps - but I'd rather not have surprises on either side too :) 15:22:57 <johnthetubaguy> Yeah 15:23:05 <johnthetubaguy> we can go through the list before the summit 15:23:16 <johnthetubaguy> but best to go through something that we have all contributed to in the mean time 15:23:19 <johnthetubaguy> if you see what I mean 15:23:51 <johnthetubaguy> #topic docs 15:23:57 <johnthetubaguy> so any updates on this stuff? 15:24:19 <matel> nope 15:24:25 <BobBall> we've hit a snag ... updates to docs are stalled ATM 15:24:25 <johnthetubaguy> OK 15:24:36 <johnthetubaguy> whys that? 15:25:19 <BobBall> technical problems that have sprung up with getting a reusable XVA 15:25:39 <johnthetubaguy> XVA of what? nova-compute VM? 15:25:42 <BobBall> which is an important Citrix goal for the summit 15:25:43 <BobBall> yup 15:26:03 <johnthetubaguy> whats up with it (can I remember how we may have fixed bits in olympus) 15:26:17 <BobBall> Mate's on the ball 15:26:21 <BobBall> it's a XS bug with networking 15:26:30 <johnthetubaguy> ah, fair enough 15:26:32 <BobBall> and the fact that we are passing the flat_network_bridge through as a kernel parameter 15:26:42 <BobBall> if you import an XVA it can screw up the networks 15:26:47 <matel> And I am working on to use hvc0 for stack.sh 15:26:59 <matel> So users can interact with the vm if needed. 15:27:02 <johnthetubaguy> OK, we used the pass the label rather than the names, which helped 15:27:16 <johnthetubaguy> but anyways, sounds good 15:27:26 <matel> Oh, does nova recognise labels as well? 15:27:27 <johnthetubaguy> anything to make getting starte easier 15:27:33 <johnthetubaguy> matel: yup 15:27:52 <matel> Ah, I didn't know that. 15:27:54 <johnthetubaguy> matel: we used that so you can create the xapi6 network, if you want, but just give it a standard name 15:28:20 <matel> xapi6 is a bridge name 15:28:27 <matel> not a networ name I guess. 15:28:36 <johnthetubaguy> yup, well, xapi-network names I was talking about 15:28:37 <matel> I will check the nova code. 15:28:46 <johnthetubaguy> sure, its in the vif drivers 15:29:10 <johnthetubaguy> looks up the network by bridge name and falls back to name-label, or something like that 15:29:13 <matel> So you say it could deal with something like "OpenStack VM Network" 15:29:28 <johnthetubaguy> I think so, but I don't remember adding spaces 15:29:41 <matel> Anyhow, it's a good tip. 15:29:52 <johnthetubaguy> #topic Bugs and QA 15:29:58 <johnthetubaguy> so, how is gating going? 15:30:41 <BobBall> eurgh... Giving up on xenserver-in-the-cloud for now. Can't get an automatic way to install it in either RS or HP clouds which means it's not suitable for -infra 15:31:06 <BobBall> so the fallback is getting it working with xenserver-core 15:31:12 <BobBall> still with devstack in domu 15:31:32 <johnthetubaguy> OK 15:31:46 <johnthetubaguy> sounds like a good plan, in terms of ssh-ing into a box 15:32:00 <BobBall> very frustrating though 15:32:01 <johnthetubaguy> any major bugs people hitting 15:32:12 <BobBall> RS cloud has some missing things I need, HP cloud has other missing things 15:32:20 <BobBall> *shakes his head frustratingly* 15:32:28 <johnthetubaguy> yeah, no one really does hypervisors in the cloud yet 15:32:44 <johnthetubaguy> I would talk to us about adding an image for xenserver core 15:32:49 <BobBall> yup 15:32:50 <johnthetubaguy> it should be possible 15:32:51 <BobBall> that'd be great 15:32:57 <BobBall> well - just use centos 15:33:00 <BobBall> then we can install xs-c :) 15:33:04 <johnthetubaguy> exactly 15:33:05 <BobBall> I've got a funky script to do that 15:33:07 <BobBall> so that's fine for me 15:33:46 <johnthetubaguy> yeah, lets get an image sorted for that testing 15:34:03 <johnthetubaguy> also, let me know what region you need 15:34:32 <johnthetubaguy> any bugs people have? 15:34:48 <BobBall> I don't think so 15:35:04 <johnthetubaguy> having real issues running block base live-migration, will raise some launchpad bugs on that one, once we pin down the errors 15:35:08 <BobBall> johnthetubaguy: don't worry about the image - I'm doing initial testing based on CentOS 6.4 only, so that's what I'm spinning up in the RS cloud 15:35:20 <matel> full tempest is failing, but that's only because the good old iscsi issue. 15:35:34 <johnthetubaguy> joy 15:35:40 <matel> exactly 15:35:59 <johnthetubaguy> BobBall: OK, if you insist 15:36:43 <BobBall> I want us to skip the iscsi tests in full tempets when running XS 15:36:52 <BobBall> so we can prove the rest is working 15:36:57 <BobBall> and doesn't regress 15:37:11 <BobBall> we know why iscsi doesn't work - and it's not an OS bug 15:37:54 <johnthetubaguy> hmm, is that the kernel thing 15:38:16 <matel> johnthetubaguy: the refactors are still waiting for you: https://review.openstack.org/#/c/46056/ https://review.openstack.org/#/c/46057/ 15:38:20 <BobBall> yes 15:38:31 <BobBall> well - actually not the kernel 15:38:46 <BobBall> the problem is because we're using netback/front and blkback/front for the same packets on the same machine 15:38:49 <BobBall> it's ugly 15:39:03 <BobBall> but it's not really an OS problem, or one you'd see in deployment 15:39:17 <BobBall> it only happens with devstack serving the iscsi volume from the same VM that is consuming it 15:39:24 <BobBall> (even for a short while) 15:39:27 <BobBall> -VM+host 15:40:03 <johnthetubaguy> oh I see 15:40:06 <johnthetubaguy> that makes sense 15:40:20 <johnthetubaguy> need the multi-machine tests to fix that 15:40:25 <johnthetubaguy> cool 15:40:28 <matel> bobball: https://github.com/openstack/nova/blob/master/nova/virt/xenapi/network_utils.py#L43 15:40:36 <BobBall> well, to be more realistic... or we need a workaround in Xen 15:40:39 <BobBall> which we're also working on 15:40:50 <BobBall> yay matel! 15:40:53 <BobBall> network name it is! 15:41:01 <johnthetubaguy> yup, its much easier that way! 15:41:29 <johnthetubaguy> cool, so 15:41:31 <matel> I will modify devstack, so we no longer depend on bridge names. 15:41:32 <BobBall> matel: but devstack should also fail earlier if we don't specify it... saves people from having a junk flat_network_bridge when it's not specified 15:41:34 <johnthetubaguy> #topic OpenDiscussion 15:41:49 <johnthetubaguy> devstack used to work with name_labels, I guess we lots that at some point 15:42:09 <BobBall> devstack will also work with name_labels I think 15:42:18 <matel> It works with labels. 15:42:36 <matel> cool stuff. 15:42:52 <matel> "OpenStack VM Network" -> osvmnet 15:43:07 <matel> "OpenStack Public Network" -> ospubnet 15:43:15 <johnthetubaguy> or "OpenStack_VM_Network" 15:43:31 <matel> is brctl happy with such long names? 15:43:39 <johnthetubaguy> it doesn't go there 15:43:43 <BobBall> why does brctl get involved? 15:43:49 <matel> nova-network. 15:44:04 <BobBall> *confused* 15:44:05 <johnthetubaguy> yeah, not sure it gets used there either 15:44:17 <BobBall> if we find the bridge then we're happy 15:44:18 <BobBall> ohhhhh 15:44:19 <BobBall> hmmmm 15:44:27 <BobBall> we might rely on the name matching 15:44:34 <BobBall> I think thjat's mate's point? 15:44:41 <johnthetubaguy> not really 15:44:49 <johnthetubaguy> nova-network will create the bridges on the fly 15:45:12 <johnthetubaguy> I can't remember quite where it gets those from now, it might be translated to xapi by that point 15:45:20 <matel> in domU u have a xapi1 bridge 15:45:33 <johnthetubaguy> yeah 15:45:46 <johnthetubaguy> but its that converted to a bridge name and saved int he db 15:45:54 <johnthetubaguy> or does the db get the name_lable 15:45:57 <matel> so it's replicating the same as it gets from /proc/cmdline 15:46:01 <matel> flat_network_bridge=xapi1 15:46:01 <johnthetubaguy> I guess its the name label 15:46:30 <johnthetubaguy> the code path isn't that simple I don't think, its the network entry in the db 15:46:32 <matel> brct show 15:46:42 <johnthetubaguy> which might be the same thing 15:46:45 <matel> brctl show 15:46:45 <matel> bridge name bridge id STP enabled interfaces 15:46:45 <matel> xapi1 8000.8e3528b79d15 no eth1 15:47:21 <johnthetubaguy> sure, I just not sure if it "name_lavbel_foo" will go to xapiN 15:48:19 <johnthetubaguy> Seems like the max length is 15 15:48:21 <matel> And I don't understand what you are saying. 15:48:24 <BobBall> perhaps it's easiest just to test it and see where it breaks :) 15:48:28 <johnthetubaguy> yeah 15:48:37 <johnthetubaguy> the config defines the look up in xapi 15:48:44 <johnthetubaguy> that goes into the DB in the network table 15:48:53 <johnthetubaguy> that is then read by nova-network when creating the bridge 15:49:01 <johnthetubaguy> can't remember if it gets changed en-route 15:49:04 <johnthetubaguy> probably not I guess 15:49:27 <johnthetubaguy> anyways, will leave that with you 15:49:32 <johnthetubaguy> anything more? 15:49:48 <matel> mysql> select bridge from networks; 15:49:48 <matel> +--------+ 15:49:48 <matel> | bridge | 15:49:48 <matel> +--------+ 15:49:48 <matel> | xapi1 | 15:49:49 <matel> +--------+ 15:49:50 <matel> 1 row in set (0.00 sec) 15:49:58 <johnthetubaguy> yeah, thats the one 15:50:10 <johnthetubaguy> I would expect xapi1 to be there 15:50:22 <johnthetubaguy> the question is, if you have its name_label in the config 15:50:28 <johnthetubaguy> do you still get xapi one in the DB 15:50:28 <matel> yes 15:50:36 <johnthetubaguy> probably not, but its worth checking 15:50:53 <johnthetubaguy> there is always the description field 15:51:02 <matel> Okay so, the question is: db_entry = lookup_bridge_name(something) 15:51:11 <johnthetubaguy> yeah 15:51:17 <matel> Okay, will check it. 15:51:22 <johnthetubaguy> I guess not 15:51:25 <johnthetubaguy> I would just test it 15:51:37 <matel> Probably not. 15:51:53 <matel> Sure, just kicking off a build after the meeting. 15:51:59 <johnthetubaguy> sweet 15:52:10 <johnthetubaguy> we all done now? 15:53:03 <johnthetubaguy> … tumble weed goes past 15:53:13 <johnthetubaguy> #endmeeting