17:01:24 #startmeeting 17:01:25 Meeting started Wed May 9 17:01:24 2012 UTC. The chair is johngarbutt. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:02:07 hello all 17:02:11 hi 17:02:11 hi 17:02:17 hi 17:02:19 I have put an agenda up for the meeting 17:02:27 #link http://wiki.openstack.org/Meetings/XenAPI 17:02:47 #topic welcome 17:03:19 we can start alphabetically :) 17:03:23 Just to introduce myself, I work for Citrix 17:03:31 sure, go for it 17:03:55 armax = Armando Migliaccio (Internap)…you might have noticed my name around the xenapi driver LOCs 17:04:12 previously with Citrix, so big fan of XenServer/XCP 17:04:22 now with Internap, but same interests ;) 17:04:37 who's next? 17:04:40 anyone before comstud? 17:04:42 :) 17:04:51 i'll just go 17:05:09 just everyone chip in at once, when it stops we can just move on :-) 17:05:19 Johannes Erdfelt, I work at Rackspace with comstud 17:05:20 chris behrens, Rackspace. We're using XenServer, so we do a lot of work in the xenapi portion of nova 17:05:48 gabe westmaas, rackspace, mostly lurking :) 17:05:51 johngarbutt = John Garbutt (Citrix) I am working on making XenServer work well with OpenStack 17:06:06 I'm Todd Deshane, technology evangelist for Xen.org. I've worked closely with the Xen+OpenStack efforts particularly with Project Kronos (xcp-xapi on Ubuntu/Debian) 17:07:05 #topic XenAPI related blueprints 17:07:36 Just wanted to get an idea of what people want and plan to do in Folsom, and lets check how it is going 17:08:04 Citrix plan to work on: Boot from volume and Live Migration, in terms of new features 17:08:48 @jerdfelt how is the work making nova deal with nova-compute restarts going? 17:08:55 good 17:09:13 i have a branch that can handle restarts during instance create and delete 17:09:17 is there a bug or blueprint to track that? 17:09:26 no blueprint yet, i'll do this today 17:09:31 cool 17:09:59 johngarbutt: can you link the blueprints for the boot from volume and live migration work? 17:10:02 I haven't got any planning yet…but I'd be happy to coordinate work with the host-aggregate blueprint 17:10:23 as I started the work at the end of essex and I am familiar with the code 17:10:50 cool, that is host-aggregates v2 right? 17:10:55 yup 17:11:05 #link https://blueprints.launchpad.net/nova/+spec/xenapi-live-migration 17:11:26 #link https://blueprints.launchpad.net/nova/+spec/xenapi-boot-from-volume 17:12:10 so for the host-aggregates it is this one: #link https://blueprints.launchpad.net/nova/+spec/general-host-aggregates 17:12:33 #link https://blueprints.launchpad.net/nova/+spec/xenapi-idempotency 17:12:47 I think the idea is to allow KVM and other use it for metadata, do work around the schedule but maintain the XenAPI pools 17:13:27 @armax looks like Joe Gordon has taken host aggregates, you OK to talk about sorting the XenAPI bits? 17:13:42 we need to get in touch with Phil Day @HP as he was the main driver for the change 17:13:53 good point, he lead the session 17:14:04 I know vish had strong ideas on that one too 17:14:32 I was there, so can fill you in on some details, but best to talk to them, as you say 17:14:50 k…that's an action item 17:15:07 #action armax to look at host-aggregates 17:15:29 @jerdfelt awesome, thanks for the link 17:15:47 what's this 'guest agent' reference on the agenda? 17:16:16 generally speaking, I am happy to forward any questions to the XenServer dev team, if that is useful 17:16:28 so let me know if Citrix can help 17:16:53 heads up on live migrate 17:17:07 it will not require shared storage 17:17:16 it is across pool 17:17:23 as far as the guest agent is concerned, it would be super-awesome if we could have something at the same level of the other openstack projects 17:17:27 currently just planning local storage -> local storage 17:17:42 comstud: do you think this is a crazy idea? 17:18:01 any news on the guest agent from rackspace people? 17:18:06 armax: No, there was a lot of guest agent discussion at the summit. Maybe too much, too many competing talks/ideas :) 17:18:27 Well 17:18:40 sorry I feel 17:18:41 We need a guest agent that works for multiple hypervisors 17:18:52 It should definitely be an openstack project 17:19:04 There's a lot of talk about configuring guests via an ec2-like metadata service 17:19:21 perhaps using cloud-init, or modifying cloud-init 17:19:23 or something compatable 17:19:35 yes, and XenAPI doesn't have config drive, which was mentioned 17:19:46 We need to have something that's easy to install into images for those that are building their own images, etc. 17:20:00 Yea, I don't think config drive is really the right long term solution.. 17:20:06 However, there are definitely people interested in that 17:20:19 At one point, we were going to mirror the functionality in xenapi.. but that hasn't happened yet 17:20:21 I tend to agree with that, its just not dynamic enough 17:20:42 comstud: multiple hypervisors and multiple guests :) 17:20:53 And we basically abandoned the idea in favor of using a metadata service 17:21:02 armax: ya :) 17:21:18 #action find if anyone is willing to do Config drive for XenAPI layer 17:21:22 as for the Windows agent….I know that RS has one 17:21:29 well I think we agree what we want 17:21:29 As is.. the guest agent we have works on Linux and FreeBSD, but it's Xen specific since communication is via xenstore. 17:21:36 well, the unix guest agent 17:21:42 Then there's also the Windows guest agent, different code base 17:21:44 is it worth considering using as a base point? 17:21:51 johngarbutt: I think there is talk of using metadata service instead of config drive as well - so that may be the first question to answer 17:21:52 both are up on launchpad (and need or are in the process of moving to github) 17:22:04 right, there was talk about the best way to share a link, personally I don't mind them being abstracted away behind a common interface 17:22:07 armax: Depends on the overall direction of how to configure guests. 17:22:17 It is somewhat pluggable as-is, though it's not quite how it needs to be 17:22:40 The communication mechanism was suppsoed to be pluggable.. currently only supporting xenstore 17:23:08 however it's very much a request/response type agent.. nothing that just automatically seeks data on boot 17:23:11 westmaas: I hurd config drive was going to use same format as metadata service, used where DHCP is not wanted (micro cloud) 17:23:45 johngarbutt: ah, so it doesn't matter where the data actually is, got it 17:23:49 If we're switching to metadata type service, prob makes sense to use cloud-init as a base... or add the support into cloud-init 17:24:21 the one issue that's always come up: how to reset passwords for already-built instances, though. 17:24:37 right now, with the current agent, you can do it while the VM is running, by sending a request to the agent. 17:24:59 I wonder about using: xenstore / metadata / config drive as the same data, but different channels on boot, with fall back order, but of course, only xenstore means its dynamic 17:25:59 Well, all of this is probably not really xenapi specific 17:26:03 Sounds like we should leave guest agent / config drive for another time, 17:26:07 so I dunno if this is the right place to discuss 17:26:14 agreed 17:26:15 Unless we want to make some specific changes to the current agent 17:26:23 in the meantime 17:26:41 any more on blueprints 17:26:53 I know vish wants to get a list for Folsom as soon as possible 17:27:03 lets move on to docs... 17:27:11 #topic XenAPI docs 17:27:39 I have started some draft docs on #link http://wiki.openstack.org/XenServer 17:27:58 Any news in KenP will add in some diagrams he had 17:28:24 johngarbutt: you mean Ken Pepple? 17:28:50 armax: yep, sorry Ken Pepple mentioned he might have some docs he could share 17:28:59 I'll check with him 17:29:13 I plan to add three (or so) example deployment diagrams and sets of flags 17:29:27 So people who want to go without DevStack can have a fighting chance 17:29:27 mark it as an action item 17:29:45 #action chase Ken Pepple for docs 17:29:49 yes..bear it mind that the youtube video for devstack setup is obsolete now 17:29:58 take it down 17:30:23 Anyone else keen to help? A quick review to see if it makes sense, would be awesome 17:30:23 which would bring me to the QA topic, but I don't wanna jump the gun 17:31:08 #action Find some people who will give the XenServer docs on the wiki a review 17:31:14 #topic XenAPI QA 17:31:24 I plan to try to help with that 17:31:27 keep me in the loop 17:31:33 So I have started getting some scripts for Citrix to run tests internally 17:31:51 I plan to setup a local test environment soon 17:32:13 I am planning to push them into DevStack 17:32:20 I know there is something there already 17:32:45 got a few tweaks to the new devstack style, so make it a bit quicker the second time 17:33:12 #link https://github.com/citrix-openstack/qa/tree/master/jenkins/devstack-xen 17:33:34 johngarbutt, deshantm: it would be good to fix XS support for devstack stable/essex 17:33:46 as it's been left broken 17:33:54 hoping to test: XenServer, XCP, xcp-xapi in Ubuntu 17:33:59 what is broken? 17:34:10 devstack on stable/essex for XS/XCP 17:34:19 there was a massive cock-up right at the release point 17:34:29 Oh... I missed that 17:34:29 some changes didn't get merged 17:34:41 #action fix devstack essex/stable 17:34:50 and if you checkout devstack essex/stable, you end up having a broken xs support 17:35:06 the fix should be pretty simple 17:35:18 its on my list 17:35:30 I meant to get essex stable tests running on every checkin 17:35:35 eventually 17:35:58 for completeness, devstack changes in progress for ci work: https://github.com/citrix-openstack/devstack/tree/xenserver-ci-improvements 17:36:24 also devstack changes to make it work with xcp-xapi (not yet working, but closer than trunk) 17:36:37 https://github.com/citrix-openstack/devstack/tree/xcp-xapi 17:37:07 I ran tempest, most things are working, but there seem to be a few issues, I will probably raise some bugs and take a look 17:37:40 two failures: keystone and because I don't have an image with the guest agent that allows key changes 17:37:53 lets move on... 17:38:01 #topic AOB 17:38:17 Questions from the summit: 17:38:34 Fedora and XCP - work is starting, but nothing you can use yet 17:38:59 xcp-xapi is in Ubuntu 12.04 17:39:08 means you get X windows in dom0, if you want 17:39:23 so you can have eclipse running to edit your sources that are running in the domU 17:39:38 trying to pull docs for that on the wiki 17:39:53 python 2.6 in dom0, probably not before this time next year 17:40:07 although there might be a sup pack (unsupported) we can release sooner 17:40:22 Other things? 17:41:04 Renuka has reworked DevStack, if you have not seen that recently, we install ubuntu over the network, so create the domU from scratch 17:41:55 Any thing else people want to raise? 17:42:42 we have some material to start with 17:43:12 how about voting which activities should have precedence? 17:43:31 e.g. new features vs docs vs qa vs devstack 17:44:02 I can try... 17:44:04 I'd rather see better docs, and qa these next milestons 17:44:24 +1 17:45:02 should the docs be back ported to essex 17:45:10 should the qa start on folsom or essex? 17:46:29 Ok, so things seem to have gone cold, and I need to run, so I will schedule another in a month if people think it is useful to keep in touch? 17:47:02 #action johngarbutt to organise another meeting in one month 17:47:44 #endmeeting