17:05:39 <johnthetubaguy> #startmeeting XenAPI
17:05:40 <openstack> Meeting started Wed Feb 13 17:05:39 2013 UTC.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:05:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:05:43 <openstack> The meeting name has been set to 'xenapi'
17:06:15 <johnthetubaguy> hello everyone
17:06:22 <matelakat> hi
17:06:37 <Mr_T> howdy
17:06:42 <antonym> hi
17:06:48 <johnthetubaguy> I see there are a few things on the wiki page to talk about
17:06:53 <johnthetubaguy> #topic agenda
17:07:01 <johnthetubaguy> #link http://wiki.openstack.org/Meetings/XenAPI
17:07:08 <johnthetubaguy> #topic blueprints
17:07:40 <johnthetubaguy> Anyone got anything to raise about blueprints this week?
17:07:55 <johnthetubaguy> I have just added a summit session for the XenAPI roadmap for Havana
17:08:01 <matelakat> It seems one of my blueprints was delayed
17:08:10 <johnthetubaguy> you got a link?
17:08:18 <matelakat> #link https://blueprints.launchpad.net/nova/+spec/xenapi-volume-drivers
17:08:28 <johnthetubaguy> how much is left?
17:08:53 <matelakat> Not too much, the main problem, is that I would rather concentrate on the glance integration
17:08:53 <toanster> hi
17:09:04 <matelakat> THat gives us new functionality.
17:09:19 <johnthetubaguy> that is the XenAPI Cinder driver right?
17:09:29 <matelakat> #link https://blueprints.launchpad.net/cinder/+spec/xenapinfs-glance-integration
17:09:34 <matelakat> Yes.
17:09:49 <matelakat> I posted a blog entry on xenapinfs - glance integration
17:09:57 <matelakat> #link http://blogs.citrix.com/2013/02/12/xenapinfs-integrated-with-glance/
17:09:59 <johnthetubaguy> cool, thanks
17:10:04 <matelakat> If anyone is interested.
17:10:35 <johnthetubaguy> That should help with documentation stuff I guess
17:10:35 <matelakat> So I would like to add the generic implementation as well, so it could deal with other image types as well.
17:10:53 <matelakat> Anyone tried XenAPINFS?
17:10:55 <johnthetubaguy> I would put the driver refactor above generic glance integration myself, but that is your call
17:11:16 <johnthetubaguy> I tried it the one time, but not since you added the glance stuff!
17:11:22 <matelakat> Okay.
17:11:31 <matelakat> oh, btw, I set up CI jobs for it.
17:11:42 <johnthetubaguy> internal to Citrix CI right?
17:11:52 <matelakat> y, But leave it for the qa section
17:11:58 <johnthetubaguy> for sure
17:12:09 <matelakat> Okay, so that's it.
17:12:14 <johnthetubaguy> any more blueprints on the edge?
17:12:19 <matelakat> What other blueprints do we have pending?
17:13:14 <johnthetubaguy> not sure I spotted any
17:13:30 <matelakat> I just looked at the configdrive, it is marked as completed.
17:13:42 <johnthetubaguy> is it complete?
17:13:49 <matelakat> marked as implemented.
17:13:51 <johnthetubaguy> I guess there are edge cases to worry about?
17:14:04 <matelakat> I haven't tried it myself.
17:14:22 <matelakat> Do I need the latest cirros for trying that?
17:14:43 <matelakat> I see release 0.3.1
17:15:02 <johnthetubaguy> not sure
17:15:07 <johnthetubaguy> depends on cloud-init version
17:15:18 <matelakat> I see.
17:15:25 <johnthetubaguy> smoser should be able to tell you
17:15:51 <matelakat> ok.
17:16:02 <johnthetubaguy> #topic docs
17:16:23 <johnthetubaguy> I guess we need to make sure how the doc bugs for XenAPI are going
17:16:34 <johnthetubaguy> anyone fancy taking a look at some?
17:16:58 <johnthetubaguy> I guess XenAPI NFS stuff we need something, not sure how the Cinder docs are doing
17:17:34 <matelakat> John, how much time do we have for the doc -ing?
17:17:59 <johnthetubaguy> till release I guess, not sure how it will work this time
17:18:02 <matelakat> Or those patches are welcome at any time?
17:18:07 <johnthetubaguy> depends on any translation freezes
17:18:20 <matelakat> Oh, let me look at the schedule.
17:18:25 <johnthetubaguy> worst case it will just sit in a queue till it opens
17:18:32 <johnthetubaguy> they are good about backports
17:18:57 <johnthetubaguy> previous docs released after the code
17:19:03 <matelakat> #link http://wiki.openstack.org/GrizzlyReleaseSchedule
17:19:09 <johnthetubaguy> but I know there was a hope with string freezes to bring that forward
17:19:19 <matelakat> It doesn't show the translation freeze.
17:19:45 <johnthetubaguy> String freeze is to help the docs and translation, but not the docs translation I guess
17:19:48 <matelakat> Or is it the same?
17:19:50 <matelakat> ah
17:20:07 <pvo> o/
17:20:11 <pvo> sorry I'm late.
17:20:13 <pvo> chatty today
17:20:24 <matelakat> hi
17:20:34 <johnthetubaguy> #link http://wiki.openstack.org/StringFreeze
17:20:42 <johnthetubaguy> Thierry says it best
17:21:14 <johnthetubaguy> pvo: hi!
17:21:27 <johnthetubaguy> OK so lets go to bugs
17:21:36 <johnthetubaguy> #topic bugs and QA
17:22:38 <johnthetubaguy> #link https://bugs.launchpad.net/devstack/+bug/1119268
17:22:39 <uvirtbot> Launchpad bug 1119268 in devstack "XS devstack fails to install on Quantal" [Undecided,Fix released]
17:22:59 <johnthetubaguy> so that was in the agenda, following on from last week
17:23:27 <matelakat> Yes, we successfully installed a devstack - quantal combo.
17:23:50 <johnthetubaguy> I have a private branch looking to simplify the scripts, but not had time to work on that beyond a quick stab
17:23:58 <johnthetubaguy> on github
17:24:12 <johnthetubaguy> any other XenAPI bugs people want to discuss
17:24:22 <matelakat> Is armando around?
17:24:41 <matelakat> live block migration bugs.
17:24:54 <pvo> johnthetubaguy: not a bug per se, but we're looking to do some "diagnostics" on a vm that a support person would execute.
17:24:55 <matelakat> But it's not strictly xenapi, I think.
17:25:11 <pvo> basically calls that any support person would execute when first investigating an issue
17:25:18 <pvo> would love some of your thoughts on things we would want to include.
17:25:29 <johnthetubaguy> nova-api extensions or more specific?
17:25:38 <pvo> there is a 'diagnostics' extension in the nova api
17:25:47 <pvo> but we're wanting to do some xen specific checks
17:25:53 <johnthetubaguy> got ya
17:25:55 <pvo> which would likely be some xenapi plugins
17:26:18 <johnthetubaguy> things like Dom0 resource levels, but I guess that is more monitoring
17:26:23 <matelakat> pvo: is there any blueprint for that, or some other info?
17:26:24 <pvo> ideally we could develop the extensions without having to modify too much nova code
17:26:41 <johnthetubaguy> right, makes sense
17:26:43 <pvo> matelakat: not yet. We're just forming thoughts around it now. Not sure if its too late for blueprints in this cycle.
17:26:47 <pvo> can get it going for the next one though.
17:27:02 <pvo> I'll get a bp started and we can add to it.
17:27:08 <matelakat> cool.
17:27:32 <johnthetubaguy> there was a really good session (maybe two summits ago) where devops guys went through the main pain they were seeing
17:27:44 <johnthetubaguy> it might be good to have a more structured version of that
17:28:02 <bobba> Sorry guys - I know I'm late!
17:28:12 <pvo> johnthetubaguy: thats exactly what I want
17:28:18 <johnthetubaguy> the think that comes to mind are Xen health checks, like resource levels
17:28:31 <johnthetubaguy> rabbit queue lenghts are interesting
17:28:44 <pvo> there are checks on the hypervisor and checks on what the vm is doing.
17:28:50 <pvo> also looking for things like noisy neighbors, etc.
17:29:02 <johnthetubaguy> right, looking for average load on the VMs
17:29:06 <johnthetubaguy> or something like that
17:29:08 <bobba> XAC can show some useful things like resource levels - we're thinking about exposing them through a supplemental pack
17:29:24 <johnthetubaguy> XAC?
17:30:36 <matelakat> I am not sure what Bob meant with the XAC. Let's wait, until he reconnects.
17:30:42 <johnthetubaguy> cool, you back, XAC?
17:30:44 <bobba> sorry - dunno what happened there guys
17:31:13 <matelakat> Bob, did you mean the javascript stuff?
17:31:14 <johnthetubaguy> what was XAC again?
17:31:18 <bobba> XAC, yes, it's a useful little tool to do some very lightweight management of a XS host
17:31:28 <matelakat> #link https://github.com/jonludlam/xac
17:31:28 <pvo> bobba: where would I find more info on that?
17:31:30 <pvo> ah
17:31:36 <johnthetubaguy> oh right, that fella
17:31:48 <johnthetubaguy> talks straight to XenAPI right?
17:31:53 <johnthetubaguy> via javascript
17:31:58 <bobba> That's the one
17:32:05 <bobba> #link xac
17:32:08 <bobba> sorry!
17:32:13 <bobba> #link https://github.com/jonludlam/xac
17:32:14 <matelakat> Okay, so if that's Xapi, it should be easy.
17:32:54 <johnthetubaguy> it is certainly a nice visual tool to check the "heath" of the hypervisor
17:33:12 <johnthetubaguy> my worry is not stamping on monitoring things
17:33:26 <johnthetubaguy> they are clearly different though
17:33:29 <pvo> looks interesting. Would have to figure out how to get it to scale
17:33:42 <bobba> it's got some charts there
17:33:43 <johnthetubaguy> it just sits on each hypervisor
17:33:49 <bobba> doesn't really scale pvo
17:33:58 <bobba> but it's useful to look at individual hosts
17:34:08 <bobba> I guess the scalable monitoring would be through ceilometer?
17:34:42 <johnthetubaguy> I worked with these guys once http://real-status.com/
17:34:53 <johnthetubaguy> very cool collection and visualization
17:34:58 <johnthetubaguy> but not open source
17:35:10 <matelakat> I think we are going too far.
17:35:15 <johnthetubaguy> anyway, certainly worth some thought
17:35:17 <johnthetubaguy> later
17:35:19 <johnthetubaguy> indeed
17:35:26 <matelakat> Let's whiteboard some ideas
17:35:41 <matelakat> I guess pvo will register a bp.
17:35:47 <pvo> bobba: scale meaning, if we built it into another tool to do diags on a host
17:36:20 <pvo> matelakat: planning on doing that this afternoon. Or actually training someone on building BPs. You'll see one, but it likely won't be from me.
17:36:50 <matelakat> pvo: thanks
17:36:51 <johnthetubaguy> I guess providing the URL to that host is what you need to integrate, assuming you have access to that network
17:36:56 <johnthetubaguy> or some kind of proxy
17:37:22 <johnthetubaguy> anyway, lets not get too distracted I guess
17:37:22 <bobba> pvo: It just uses javascript, XAPI and the RRD information - so I imagine that would be easily portable.  However, it will only work on remote hosts in Tampa+ because that's when JSON was added
17:37:30 <johnthetubaguy> #topic Open Discussion
17:37:33 <pvo> johnthetubaguy: that and the login credentials. all our hosts are different.
17:37:46 <pvo> bobba: gotcha
17:38:14 <johnthetubaguy> pvo: right, makes me think back to integrating keystone into XenAPI again
17:39:47 <johnthetubaguy> the web gui can have a token for limited access, or something, but need thought
17:39:51 <johnthetubaguy> needs^
17:40:02 <pvo> johnthetubaguy: that would be interesting for sure.
17:40:22 <johnthetubaguy> lets jump to stuff we have on the agenda
17:40:27 <pvo> I think we'd talked about doing ldap as well for xapi.
17:40:28 <pvo> kk
17:40:59 <johnthetubaguy> right, I guess that is already there in some capacity with AD integration
17:41:19 <johnthetubaguy> so we coved XenAPI NFS blog already
17:41:23 <johnthetubaguy> #link https://review.openstack.org/#/c/15022/
17:41:31 <bobba> LDAP on xenserver is very possible, but it does need some tuning and a few extra packages installed
17:42:05 <matelakat> Oh, yeah, ovs.
17:42:11 <johnthetubaguy> talk of XenServer supplemental pack
17:42:31 <johnthetubaguy> I guess that review includes extra plugins
17:42:54 <johnthetubaguy> there is also talk of python26 packages, git, puppet, and others
17:42:57 <bobba> Yeah - that's right.  So I was thinking, I think that the only reason that devstack pulls via a zipball is because we don't have git in dom0?
17:43:14 <johnthetubaguy> right
17:43:27 <johnthetubaguy> EPEL can give you that if you want it for dev
17:43:39 <johnthetubaguy> we used to do it that way
17:43:53 <johnthetubaguy> but moved away for reasons that escape me
17:43:55 <bobba> Okay.  So we're planning to produce a supplemental pack that can be installed on a XenServer that will install python 2.6 - I was wondering if pulling in git and simplifying the XenServer devstack setup scripts would be a good option
17:44:07 <antonym> git would be great :)
17:44:25 <johnthetubaguy> it has to be handy for pulling dev ops scripts too right
17:44:34 <bobba> I'm sure!
17:44:38 <antonym> definitely
17:45:10 <matelakat> Give me an action on looking at that.
17:45:11 <bobba> What else are people dying for in dom0?  Clearly the best things to consider are ones that don't affect the base XS installation
17:45:16 <johnthetubaguy> Maybe these can be separate sup packs, since there is not much overhead in the suppack?
17:45:28 <matelakat> +1 for many small suppacks
17:45:35 <johnthetubaguy> matelakat: look at what?
17:46:05 <zykes-> is there plans to land Ceilometer support for XenServer?
17:46:15 <antonym> small supp packs would work, then you could have a chef and a puppet pack seperated if needed
17:46:17 <matelakat> look at the suppack creation, and how hard it is. So on the next meeting, I could show some progress.
17:46:26 <johnthetubaguy> antonym: you read my mind
17:46:35 <bobba> Ceilometer for XenServer is being looked at for Grizzly.  I haven't caught up with rfy
17:46:43 <bobba> sorry! premature-enter pressing
17:47:02 <bobba> yjing5 (I think, can't quite remember his IRC nick) was looking at Ceilometer for XenServer.
17:47:08 <johnthetubaguy> yep someone form intel was taking a look, not sure if sandy was too
17:48:05 <johnthetubaguy> #action matelakat to look at suppack for git, python26 (with pip), puppet
17:48:32 <johnthetubaguy> supplimental pack is an rpm + metadata, there is a public SDK with tools to build them
17:48:59 <johnthetubaguy> there are some old build scripts that could help on git hub in the geppetto bits I think
17:48:59 <pvo> zykes-: yes, we're working on Ceilometer and Xen support at RAX
17:49:04 <bobba> Actually part of the "DDK" - driver development disk
17:49:14 <johnthetubaguy> thats the name, cheers
17:49:19 <zykes-> oh ! :)
17:49:19 <pvo> it may be further out for fully supported however,
17:49:28 <matelakat> Okay, I'll look at it, I just wanted a record of that intention.
17:49:31 <bobba> driver development __kit__
17:49:35 <pvo> sandywalsh is working on that
17:50:02 <matelakat> pvo: on the suppack packaging?
17:50:21 <johnthetubaguy> ceilometer I think
17:50:22 <pvo> matelakat: no, sorry. on the ceilometer xenserver support.
17:50:27 <matelakat> ok.
17:50:38 <johnthetubaguy> cool, any more on those bits?
17:50:47 <johnthetubaguy> looks promising on python26 et al
17:51:07 <johnthetubaguy> official stuff will look good
17:51:27 <zykes-> python what johnthetubaguy ?
17:51:34 <johnthetubaguy> OK, next item is "Getting images suitable for use in XenServer: Ideal source, format and mechanism for uploading."
17:51:55 <johnthetubaguy> zykes: supplemental pack that contains python26 to run in Dom0
17:51:58 <zykes-> ok :)
17:51:59 <bobba> yeah - I raised that one
17:52:22 <johnthetubaguy> mate had a blog post on some fun ways to do some of this
17:52:29 <johnthetubaguy> but the docs are very lacking
17:52:35 <bobba> There's one image (ubuntu lucid) that I know about - I think someone at RAX generated that
17:52:42 <matelakat> So we are using this image here: #link https://github.com/citrix-openstack/warehouse
17:52:49 <johnthetubaguy> particularly all the semi-secret glance flags
17:52:50 <matelakat> for testing.
17:53:01 <bobba> I'm concerned that the blog post is a little too difficult for mainstream really
17:53:23 <bobba> I noticed that Canonical(?) are hosting a whole bunch of qcow2 images for openstack consumption
17:53:31 <johnthetubaguy> right
17:53:44 <bobba> I wondered if there is any way we can capitalise on those, or have VHD images that we can use in a different way
17:53:50 <johnthetubaguy> there was a chat at the summit about that, or prehaps the ubuntu conference
17:54:04 <matelakat> Is there any way to use those qcow images with XenServer?
17:54:07 <johnthetubaguy> Mike McClurg had contacts with Ubuntu about their cloud images and getting VHD ones
17:54:35 <johnthetubaguy> I know comstud has some code for doing raw->vhd using vhd util
17:54:47 <bobba> oh does he
17:54:54 <johnthetubaguy> basically there is no way for ubuntu to generate xenserver "happy" vhd files currently
17:54:59 <bobba> I can get in touch with Mike and see what the score is with Canonical
17:55:07 <bobba> yeah - we patch VHD util for performance reasons
17:55:17 <bobba> the original VHD spec doesn't do everything we'd want
17:55:27 <matelakat> #link http://blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd/
17:55:29 <johnthetubaguy> block alignment I guess, the stuff added to VHDX
17:55:42 <matelakat> #link http://blogs.citrix.com/2012/10/17/upload-custom-images-to-a-xenserver-powered-openstack-cloud/
17:55:49 <johnthetubaguy> yep, its basically giving people some of these tools that will help things along
17:56:11 <matelakat> John, do you know about any tricks to get qcow working on XS?
17:56:18 <johnthetubaguy> I know comstud was thinking about linking vhdutil from qemu-img convert
17:56:35 <johnthetubaguy> erm, not actually tried, it involves hacking the SM scripts I think
17:56:40 <johnthetubaguy> which are python at least
17:57:04 <bobba> it'd be nice to get the vhdutil from XS upstream into qemu
17:57:10 <matelakat> could you mail me a contact person to discuss it with?
17:57:12 <johnthetubaguy> you can do it with XL underneath, but there is no blk back driver or something
17:57:34 <johnthetubaguy> qcow?
17:57:49 <johnthetubaguy> storage architect you want
17:57:52 <matelakat> ok
17:57:55 <johnthetubaguy> keith petley
17:58:02 <matelakat> ta
17:58:07 <johnthetubaguy> (+ spelling corrections)
17:58:48 <johnthetubaguy> I think you can do raw by adding raw files and some small hacks
17:58:54 <johnthetubaguy> which is another option
17:59:05 <johnthetubaguy> BobBall: what was your exact question
17:59:17 <johnthetubaguy> around images?
17:59:36 <johnthetubaguy> bobba: I mean
17:59:45 <bobba> I'm not sure
17:59:58 <bobba> I think a simpler way, whatever that way is, would be better
18:00:14 <bobba> for example us using qcow2 images, or automatically converting on upload or something like that
18:00:21 <johnthetubaguy> I guess updaing horizon to support Xen related upload options would help
18:00:45 <johnthetubaguy> maybe scritps that wrap the glance cli that add the appropriate extra keys
18:00:56 <johnthetubaguy> or glance cli extensions
18:01:06 <johnthetubaguy> ah, ok
18:01:10 <johnthetubaguy> you mean image formats
18:01:23 <johnthetubaguy> I always assume people would prep on the XenServer and export the vhd
18:01:29 <bobba> yeah
18:01:36 <johnthetubaguy> we are out of time, so we should wrap up
18:01:45 <matelakat> I think we could support other type of images easily - if we use qemu-img convert to pipe the bytes to the attached vdi.
18:02:10 <bobba> I think that's fine for small or huge deployments - but I guess some people want to consume other images - hence the market for the ubuntu qcow2 ones?
18:02:13 <johnthetubaguy> OK, this goes back to having a glance "convert" kind of function, possible using a conversion worker
18:02:13 <matelakat> But that's only one direction.
18:02:36 <johnthetubaguy> then glance supporting multiple disk types against a single image "parent" maybe
18:02:42 <bobba> I've had a couple of guys asking me directly for XS images - the qcow2 ones are easily linked from OS documentation at the moment
18:02:44 <bobba> just a thought :)
18:03:17 <johnthetubaguy> you can use the three part raw amazon image directly though I think
18:03:32 <bobba> oh yes that's true
18:03:35 <johnthetubaguy> could be wrong on that one, maybe you need tools
18:03:37 <bobba> the ami images?
18:03:42 <johnthetubaguy> yes
18:03:43 <johnthetubaguy> anyways
18:03:45 <johnthetubaguy> we are out of time
18:03:59 <bobba> I did that today! :)
18:04:01 <bobba> true
18:04:10 <johnthetubaguy> :-)
18:04:21 <johnthetubaguy> #endmeeting