15:01:32 <johnthetubaguy> #startmeeting XenAPI
15:01:33 <openstack> Meeting started Wed Aug  7 15:01:32 2013 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:36 <openstack> The meeting name has been set to 'xenapi'
15:01:47 <johnthetubaguy> hello, who is around today?
15:01:50 <BobBall> I am
15:02:05 <matel> am
15:02:15 <johnthetubaguy> cool, any agenda items?
15:02:20 <euanh> here
15:02:38 <BobBall> sure - euanh should give an update on xenserver-core and deb and ARM
15:02:44 <BobBall> I can give an update on xenserver-core and dom0
15:03:06 <johnthetubaguy> OK, stuff for the open discussion I guess
15:03:29 <BobBall> there's been a lot of activity around XenAPI this week
15:03:32 <BobBall> very interesting to see
15:03:54 <johnthetubaguy> yes, list seemed to be hotting up again
15:04:05 <johnthetubaguy> #topic Blueprints
15:04:09 <johnthetubaguy> any updates?
15:04:28 <johnthetubaguy> just a heads up there are a few XenAPI bits and bobs from Rackspace coming in
15:04:36 <johnthetubaguy> just debating a few in the ML
15:04:37 <BobBall> I saw them
15:04:44 <BobBall> new blueprints coming in - tis very good
15:04:48 <johnthetubaguy> I am defending the ones I like :)
15:05:10 <BobBall> successfully too
15:05:11 <johnthetubaguy> Ant has a very cool idea with the VNC access to a PXE installer
15:05:19 <BobBall> what's that?
15:05:23 <johnthetubaguy> #link https://blueprints.launchpad.net/nova/+spec/xenapi-ipxe-iso-boot-support
15:05:33 <BobBall> oh I see what you mean
15:05:33 <BobBall> yes
15:05:47 <BobBall> perhaps a question about that
15:05:56 <johnthetubaguy> basically boot up an ISO, then it does PXE boot, but inject the networking into the ISO, so user doesn't need to configure networking in non DHCP
15:05:58 <BobBall> I'd agree with Russell - why not glance?
15:06:17 <johnthetubaguy> it wouldn't work in glance, glance doesn't control how Xen boots a VM
15:06:17 <antonym> BobBall: it resides in glance, we're just automating the static ip portion of it
15:06:27 <johnthetubaguy> yeah, thats a good point
15:06:31 <johnthetubaguy> the ISO lives in glance
15:06:41 <johnthetubaguy> then when it boots we need to inject the network settings
15:06:45 <antonym> we have to regererate the iso in order to inject the ips directly in it, only way we could think of to completely bypass dhcp
15:06:47 <BobBall> I mean why is it nova that is configuring it rather than being able to DL a configured image or something - wasn't that the suggestion?
15:07:16 <antonym> if glance handles it, don't we have to pass networking info back to glance?
15:07:29 <BobBall> true
15:07:40 <johnthetubaguy> yeah, its just a mess that way
15:07:51 <johnthetubaguy> but people haven't seen that yet, hopefully they will soon :)
15:07:58 <BobBall> I've got it - create one image for every IP that you've got - then just download the right one! ;)
15:08:03 <antonym> seemed to be much simpler just to shim it into boot from iso within nova
15:08:09 <antonym> lol
15:08:18 <antonym> we'll make an iso per ip :P
15:08:21 <johnthetubaguy> its quite different to an image builder, it lets you access the installer via VNC
15:08:29 <johnthetubaguy> lol, that would do it!
15:08:53 <antonym> it shifts the logic of image building out of openstack using all the things ipxe has to offer
15:09:18 <antonym> could even generate ipxe ks.cfgs based on mac address of the instance, but that's stuff we're looking at next
15:09:29 <BobBall> okay
15:09:32 <BobBall> sounds great to me
15:09:36 <johnthetubaguy> sweet, that makes good sense
15:11:49 <johnthetubaguy> so, any more on blueprints
15:12:48 <matel> If anyone has time to do a review: #link https://review.openstack.org/#/c/39496/
15:13:11 <matel> Working on xenapi-supported-image-import-export
15:13:34 <matel> #link https://blueprints.launchpad.net/nova/+spec/xenapi-supported-image-import-export
15:13:43 <johnthetubaguy> OK, is that looking like it will make Havanna?
15:14:18 <johnthetubaguy> the blueprint that is
15:14:21 <matel> Depends on the review speed.
15:14:32 <matel> And maybe I am doing too many changes.
15:14:37 <BobBall> yes, we want it in Havana
15:14:47 <BobBall> we're aiming to have it completed in the next week or two
15:14:59 <matel> So if you guys think, that these changes/refactors are too big, please let me know.
15:15:04 <johnthetubaguy> OK, need all code up about now to get it in Havana I expect
15:15:30 <johnthetubaguy> I don't think we should be doing qemu-img convert during a glance download
15:15:59 <johnthetubaguy> the main reason is glance is build async workers to do image conversion
15:16:18 <johnthetubaguy> so the converted image gets done as part of image upload, so it only needs to be converted once
15:16:39 <johnthetubaguy> let me find a bp for that...
15:16:45 <matel> Is that feature will be in havana?
15:16:54 <johnthetubaguy> nope
15:17:08 <johnthetubaguy> well, not in a useful way, I expect
15:18:43 <johnthetubaguy> well, it seems to be this:
15:18:44 <johnthetubaguy> https://blueprints.launchpad.net/glance/+spec/new-upload-workflow
15:18:48 <johnthetubaguy> so maybe it will make it
15:18:52 <matel> So I understand, that the same functionality will be covered by this glance feature, but we would like to provide a way to use xenserver without the glance/vhd plugins.
15:19:17 <johnthetubaguy> what format does it need to be in, to use it without the glance plugin?
15:19:35 <matel> Any qemu-img supported format.
15:20:15 <johnthetubaguy> maybe I don't understand how you are using the supported route?
15:20:38 <johnthetubaguy> why does it need a convert then, you could just upload the correct version to glance right?
15:20:43 <johnthetubaguy> not version, I mean format
15:20:45 <matel> So, basically: create a vdi, attach to domU, pipe in the bytes from glance, create another vdi, convert the first to the second.
15:20:57 <matel> using qemu img in domU
15:21:14 <johnthetubaguy> OK, like we do with raw today?
15:21:18 <johnthetubaguy> sort of
15:21:28 <matel> yes, sort of.
15:21:37 <matel> But basically that's the idea.
15:21:57 <johnthetubaguy> well, if you can get people to upload the correct type to glance, presumably you don't need to do the convert any more?
15:22:17 <matel> So that leaves us with raw.
15:22:21 <johnthetubaguy> right
15:22:29 <johnthetubaguy> that could work though?
15:22:47 <johnthetubaguy> just add raw + ovf packaging, and its not too big
15:23:09 <matel> Sounds like an xva.
15:23:14 <johnthetubaguy> yup
15:23:25 <johnthetubaguy> similar
15:23:30 <matel> And would you support this idea?
15:23:39 <johnthetubaguy> sure, seems fine
15:23:53 <johnthetubaguy> its the conversion bit I don't ike
15:23:56 <johnthetubaguy> like^
15:23:59 <matel> I see.
15:24:10 <johnthetubaguy> because that is going to get done in glance
15:24:16 <johnthetubaguy> and could be done once, and outside nova
15:24:29 <johnthetubaguy> seems wrong to do that inline, but maybe I am missing something?
15:25:36 <matel> I don't have problems with that, if that gives us value.
15:26:20 <matel> And the real issue now is that we don't have a sparse format.
15:26:48 <johnthetubaguy> but raw that is then compressed, will have most of the zero blocks compressed quite quickly
15:26:56 <johnthetubaguy> its not too bad
15:27:03 <johnthetubaguy> (probably)
15:27:28 <matel> Well.
15:27:32 <johnthetubaguy> I am assuming we keep the existing VHD route, just its unsupported.
15:27:47 <matel> sure, I don't want to change that.
15:28:07 <johnthetubaguy> cool, that all make sense to me then
15:28:17 <matel> One q.
15:28:21 <johnthetubaguy> sure
15:28:25 <matel> virtual size - physical size
15:28:32 <johnthetubaguy> yes
15:28:43 <matel> so I think glance reports only the physical
15:29:13 <matel> I guess I would need to have some sort of metadata in the beginning of the tar file.
15:29:15 <johnthetubaguy> yes, that probably
15:29:26 <johnthetubaguy> why?
15:29:36 <matel> Maybe xapi can do this stuff alone, I need to check it with DS
15:29:52 <matel> I am just thinking about the implementation steps.
15:29:52 <johnthetubaguy> oh, I see what you mean
15:29:56 <johnthetubaguy> you need to know the size
15:30:02 <matel> Yes, to create the vdi
15:30:08 <johnthetubaguy> well, turns out you have the size, its in the flavor
15:30:19 <johnthetubaguy> and if it doesn't fit, you just die
15:30:45 <matel> that could work - optimization later.
15:30:47 <johnthetubaguy> there check between glance and the flavor already to check that you don't put it in the wrong size
15:31:01 <johnthetubaguy> call min_disk_gb, or something similar
15:31:11 <matel> Yes, that rings a bell.
15:31:23 <johnthetubaguy> not sure it needs optimization, the protection is already there
15:31:29 <matel> Anyhow, I need to speak about this stuff with bob.
15:31:34 <johnthetubaguy> OK
15:31:48 <johnthetubaguy> afraid I am on holiday from tomorrow till a week on monday
15:31:58 <matel> Good for you, enjoy!
15:32:13 <johnthetubaguy> some emails may get answered, but I am in a field for the first bit of the holiday!
15:32:27 <johnthetubaguy> Ok, that was a useful discussion I think
15:32:31 <johnthetubaguy> lets move on
15:32:34 <matel> sure.
15:32:44 <johnthetubaguy> #topic docs
15:33:04 <johnthetubaguy> not updates from me on this one, I still need to follow up on that blueprint and bugs
15:33:11 <johnthetubaguy> no updates^
15:33:24 <johnthetubaguy> #topic Bugs and QA
15:33:35 <johnthetubaguy> any updates for gating stuff?
15:34:07 <BobBall> Only that the xenserver-core stuff is going well and that might be an alternative route to gating
15:34:28 <johnthetubaguy> cool
15:34:39 <BobBall> I was expecting to do some of the zuul dependencies this week
15:34:44 <johnthetubaguy> #topic Open Discussion
15:34:46 <BobBall> but I've been too busy on other things
15:34:56 <BobBall> such as answering RAX questions ;)
15:35:12 <johnthetubaguy> cool, I jumped on to Open, fire away
15:35:23 <johnthetubaguy> BobBall: hehe, as you should :)
15:35:46 <BobBall> euanh is jumping back in to give an update on xenserver-core, DEB, packaging and ARM
15:36:10 <euanh> I'm working on the build system for XenServer Core
15:36:20 <euanh> RPM building works pretty well
15:36:43 <euanh> I'm adapting that to build DEBs because the Xen on ARM work is Debian based
15:37:18 <euanh> for our uses the mapping from RPM to DEB is fairly straightforward but there are some fiddly bits
15:37:42 <euanh> Once I have DEBs I can rebuild them for ARM
15:38:15 <johnthetubaguy> sounds cool
15:38:55 <johnthetubaguy> is that getting pushed back into Ubuntu as the new xcp-xapi packages?
15:38:55 <BobBall> We've already had a POC with openstack running on the RPMs
15:39:10 <BobBall> xcp-xapi is being replaced eventually
15:39:15 <BobBall> with xenserver-core
15:39:17 <johnthetubaguy> awesome, I saw some bugs, so I guessed it should have got somewhere
15:39:35 <johnthetubaguy> sure, with an upgrade path I hope :-P
15:39:38 <BobBall> but we want the community to manage the packaging eventually...
15:39:48 <BobBall> Hope so but no promises!
15:40:00 <BobBall> xapi-xcp was a fixed point in time
15:40:08 <BobBall> it's a very strange setup
15:40:19 <BobBall> but I imagine that a deb based upgrade should probably work
15:40:25 <BobBall> since XAPI will upgrade the DB etc
15:41:29 <johnthetubaguy> would be good to see a nice version in the next LTS, but maybe its too late now
15:41:46 <BobBall> not quite too late yet
15:42:00 <BobBall> LTS for xenserver-core is probably doable
15:42:04 <BobBall> as long as it's multiverse
15:42:17 <BobBall> getting it in core would need it to be in multiverse for 13.10 which is very very tight
15:42:25 <johnthetubaguy> well has to drop in 13.10 probably, I presume, they don't like bit changes during the LTS schedue
15:42:31 <johnthetubaguy> oh, right I see
15:42:38 <johnthetubaguy> where is xapi-xcp now?
15:42:50 <BobBall> multiverse
15:43:09 <johnthetubaguy> yeah, they will probably be OK about that hopefully
15:43:15 <johnthetubaguy> cool, good to see it get sorted finally
15:43:23 <johnthetubaguy> OK, its a bit non-openstack I guess
15:43:28 <johnthetubaguy> anything more openstack?
15:43:45 <matel> refactoring.
15:44:02 <matel> Are we planning to do any structuring on the code?
15:44:21 <matel> Or it's just good as it is?
15:44:39 <BobBall> it's not good as it is
15:44:44 <BobBall> and yes, we need to do some refactoring
15:45:25 <matel> So the main question is whether we want to do some official, coordinated refactoring.
15:45:40 <matel> The q goes to John mainly.
15:45:53 <BobBall> what do you mean by that?
15:45:59 <johnthetubaguy> well, its probably best we co-ordinate, otherwise we will all clash horribly
15:46:13 <matel> Yes, the conflicts are my concerns
15:46:17 <johnthetubaguy> I would raise bugs for the areas you are worried about, then take those bugs
15:46:38 <johnthetubaguy> maybe pop up an etherpad with a list of things you are worried about
15:46:44 <johnthetubaguy> what where you thinking?
15:46:57 <matel> I was thinking about a "refactor day" or something like this.
15:47:06 <johnthetubaguy> I would love to see steps towards the oslo xenapi lib to share with Cinder
15:47:25 <johnthetubaguy> hmm, I would probably want more than a day, but that could work.
15:47:42 <johnthetubaguy> what things did you want to cover?
15:48:04 <matel> Look at the change that I sent, that's an ide.
15:48:07 <matel> idea.
15:48:12 <johnthetubaguy> which change?
15:48:29 <matel> https://review.openstack.org/#/c/39496/
15:48:57 <matel> But that's a common library.
15:48:59 <johnthetubaguy> OK, that kinda in non-xenapi stuff
15:49:02 <johnthetubaguy> sorta
15:49:09 <matel> yes, but you get the "idea"
15:49:29 <johnthetubaguy> the issue is, we would reject that change, until there is no follow on code that makes use of it
15:49:35 <johnthetubaguy> I think, anyway
15:50:06 <BobBall> This is where we should have a second changeset depending on the frist :)
15:50:08 <matel> Given our xva discussion, it can happen.
15:50:42 <johnthetubaguy> yep
15:50:52 <johnthetubaguy> we should have a second change depending on it
15:51:09 <johnthetubaguy> matel: I thought we decided on no conversion?
15:51:45 <johnthetubaguy> oh, I see
15:51:47 <matel> it was uploaded Jul 31, 2013 3:42 PM
15:51:51 <johnthetubaguy> fetch to raw
15:52:29 <johnthetubaguy> matel: its a low priority blueprint, theses loads of medium and the odd high review to do first
15:52:41 <johnthetubaguy> bit of priority inversion going on here.
15:53:04 <johnthetubaguy> http://status.openstack.org/reviews/
15:53:04 <BobBall> I'd like to argue this should be higher priority
15:53:06 <matel> So, John, are you saying that we can't get this xva or whatever stuff in?
15:53:13 <BobBall> I think this should be at least a medium
15:53:27 <BobBall> since it's providing a mechanism for XS under openstack to use supported APIs
15:53:33 <BobBall> which is crucial for a supported environment
15:54:17 <johnthetubaguy> thats russells call, but there are some official definitions somewhere, I can't remember how to phrase that
15:54:49 <johnthetubaguy> its a bit late anyway to be given more priority, because we have no hope of reviewing all the current mediums
15:55:11 <matel> I think that leaves us with no options.
15:55:13 <johnthetubaguy> its a bit unfortunate, but its all too late to offer any better I guess
15:55:22 <BobBall> Doesn't mean there aren't other things that are of higher priority than the existing ones :)
15:55:40 <johnthetubaguy> indeed, but the other have code up already, so its only fair
15:55:47 <BobBall> We can chat with Russell and explain why it should be higher
15:55:57 <johnthetubaguy> sure, if you feel strongly, ask
15:56:14 <johnthetubaguy> but we need the code up yesterday for it to make much difference, if you see what I mean
15:56:35 <johnthetubaguy> anyways, hopefully it will get in
15:56:39 <johnthetubaguy> there is still hope
15:56:50 <matel> okay, we'll see.
15:56:53 <BobBall> perhaps we should do as we said last week, consider it a bug
15:57:03 <BobBall> because what happens if you try and use a cqow2 image with XS?
15:57:06 <BobBall> probably an error log
15:57:21 <matel> John is against the conversion.
15:58:04 <BobBall> but if it's only process that stops a good change getting in then maybe it's worth thinking about :)
15:58:32 <johnthetubaguy> its about review bandwidth, there is no more left
15:58:47 <johnthetubaguy> anyways, I am not sure I understand the refactor
15:58:57 <johnthetubaguy> we are out of time I guess
15:59:11 <matel> yes, have a nice holiday for the lucky ones!
15:59:20 <johnthetubaguy> I thought we agreed no conversion, so we just are importing raw here?
15:59:25 <BobBall> indeed
15:59:27 <BobBall> oh
15:59:28 <johnthetubaguy> one last question
15:59:41 <johnthetubaguy> what do we need to change, to make importing raw supported?
15:59:58 <johnthetubaguy> I think it currently works OK
16:00:02 <matel> yes.
16:00:06 <matel> it works.
16:00:12 <matel> It's not sparse
16:00:53 <johnthetubaguy> OK
16:00:57 <johnthetubaguy> we are out of time now
16:01:01 <johnthetubaguy> #endmeeting