15:00:07 <johnthetubaguy1> #startmeeting XenAPI
15:00:08 <openstack> Meeting started Wed Nov 20 15:00:07 2013 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy1. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:11 <openstack> The meeting name has been set to 'xenapi'
15:00:22 <johnthetubaguy1> hello all
15:00:27 <BobBall> Hello John
15:00:28 <johnthetubaguy1> who is around for today's meeting?
15:00:37 <matel> hi John - now I know why I haven't found you on IRC :-)
15:01:11 <johnthetubaguy1> oh the name, yeah, VPN dropped on me
15:01:24 <johnthetubaguy1> #topic Blueprints
15:01:32 <johnthetubaguy1> so are people happy about Icehouse-1
15:01:40 <johnthetubaguy1> do we have any blueprints that need reviewing?
15:01:57 <matel> This is going to be quick from our side - we haven't registered any bps
15:01:58 <johnthetubaguy1> I mean the blueprints, not the code right now
15:02:10 <BobBall> Happy with I-1
15:02:24 <johnthetubaguy1> it would be good to get things lined up for I-2 soon
15:02:38 <BobBall> Agreed
15:02:40 <johnthetubaguy1> we can look at getting stuff we really one promoted to medium, if I can get more sponsors
15:02:44 <BobBall> Can you remind us when I-2 is?
15:02:50 <johnthetubaguy1> but that will need to be soon rather than later
15:03:00 <johnthetubaguy1> erm, good question, let me check the date...
15:04:26 <johnthetubaguy1> OK, so I can't find that damm page
15:04:30 <johnthetubaguy1> anyways, its soon
15:04:33 <BobBall> hehe
15:04:38 <BobBall> isn't it always :)
15:04:42 <johnthetubaguy1> I have a few blueprints up for I-1
15:04:49 <johnthetubaguy1> just finishing the stuff off
15:04:50 <matel> https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
15:04:53 <johnthetubaguy1> but reviews welcome
15:04:57 <johnthetubaguy1> ah, thank you!
15:05:10 <johnthetubaguy1> the slashes I added in that URL did not help me
15:05:32 <johnthetubaguy1> so, W/B 12th December
15:05:51 <BobBall> it's again a very short milestone
15:06:01 <johnthetubaguy1> If my stuff doesn't make I-1 I will try make them medium for I-2
15:06:02 <BobBall> I suspect most of our efforts will be focused on tempest tests in that period
15:06:16 <johnthetubaguy1> I was about to say its longer due to the holiday, but anyways
15:06:23 <johnthetubaguy1> tempest is a good thing to worry about
15:06:34 <BobBall> indeed
15:06:38 <BobBall> but not blueprintable :)
15:06:38 <johnthetubaguy1> (lets come back to that in a moment)
15:07:06 <johnthetubaguy1> well we could I guess… but ignore that
15:07:45 <BobBall> Of course we could - but I was judging from my interpretation of Russell's "what is a blueprint"
15:08:15 <johnthetubaguy1> well its doesn't touch nova code, it would probably live in qa team or something
15:08:16 <johnthetubaguy1> https://blueprints.launchpad.net/nova/+spec/xenapi-resize-ephemeral-disks
15:08:25 <johnthetubaguy1> https://blueprints.launchpad.net/nova/+spec/xenapi-vcpu-pin-set
15:08:31 <johnthetubaguy1> https://blueprints.launchpad.net/nova/+spec/xenapi-vif-hotplug
15:08:37 <johnthetubaguy1> all have some patches up now
15:08:45 <johnthetubaguy1> the last two need some work from me still
15:09:02 <johnthetubaguy1> the last one is more of a sketch than real code at this stage, but progress
15:09:10 <BobBall> so the first one is ready for review?
15:09:16 <johnthetubaguy1> yes
15:09:22 <johnthetubaguy1> so is the second one
15:09:28 <johnthetubaguy1> third one, not so much
15:09:41 <johnthetubaguy1> but its still worth a peak to see what you think
15:10:15 <johnthetubaguy1> I just pushed this one out to I-2
15:10:16 <johnthetubaguy1> https://blueprints.launchpad.net/nova/+spec/xenapi-driver-refactor
15:10:19 <matel> nice progress, John!
15:10:29 <BobBall> ok
15:10:33 <johnthetubaguy1> I think belliott was interested in the above, but not sure yet
15:10:43 <johnthetubaguy1> anyways, lets crack on
15:10:56 <johnthetubaguy1> #topic QA and bugs
15:11:21 <johnthetubaguy1> our bug list is getting very silly now
15:11:21 <johnthetubaguy1> https://bugs.launchpad.net/nova/+bugs?field.tag=xenserver
15:11:24 <johnthetubaguy1> 58 long
15:11:31 <johnthetubaguy1> OK, some are fixed, but still
15:11:46 <BobBall> First one isn't really ours
15:11:50 <BobBall> just I found it
15:11:52 <BobBall> and it affects us
15:11:55 <johnthetubaguy1> well, we could fix it
15:12:12 <johnthetubaguy1> VMware just added some stuff, and we asked them to start namespacing VMware specific stuff
15:12:36 <johnthetubaguy1> we could help come up with a baseline that can be tested, but I am too busy to help right now
15:12:53 <johnthetubaguy1> anyways, just wanted to raise that, we need some effort of getting that list of bugs under control
15:13:05 <BobBall> #link https://bugs.launchpad.net/nova/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=xenserver+&field.tags_combinato
15:13:07 <johnthetubaguy1> it might just mean me being more critical about the priorites of some
15:13:12 <BobBall> 42 not fixed
15:13:20 <johnthetubaguy1> right, its still too high
15:13:35 <johnthetubaguy1> or looks high compared to other bug groupings
15:13:43 <johnthetubaguy1> but maybe we are better at tagging
15:13:45 <johnthetubaguy1> anyways
15:13:50 <johnthetubaguy1> needs some work
15:14:07 <johnthetubaguy1> maybe beginning of Icehouse-2 we do a XenAPI bug day?
15:14:29 <johnthetubaguy1> #action johnthetubaguy1 to organise a XenAPI bug squash day
15:14:34 <BobBall> Sure
15:14:44 <johnthetubaguy1> cool, so QA?
15:14:54 <johnthetubaguy1> hows the getting tempest tests running going?
15:15:04 <johnthetubaguy1> I really want to see how I can help make this happen
15:15:22 <johnthetubaguy1> even if the test is always failing, I would love to see something on that zuul list
15:15:32 <matel> Okay, that's a separate issue
15:15:37 <BobBall> well firstly an account where we can run things in the RAX cloud for Mate would be very good
15:15:52 <johnthetubaguy1> sure, sign up for a free developer account
15:15:57 <matel> That's why I wanted to contact you John.
15:16:04 <matel> Ah, OK, will do that.
15:16:10 <johnthetubaguy1> matel: http://developer.rackspace.com/devtrial/
15:16:38 <matel> I hope it doesn't ask for my cc details.
15:16:40 <BobBall> the 6-month thing is the bit I'm just hitting up against with mine
15:16:43 <BobBall> it will Mate
15:16:44 <johnthetubaguy1> if you need more to make this happen, then… get euan to sign up
15:17:04 <matel> Can we get a proper account somehow?
15:17:12 <johnthetubaguy1> it is a proper account
15:17:20 <johnthetubaguy1> maybe I am missing something?
15:17:33 <matel> So: I won't give any cc details here.
15:17:51 <BobBall> You can't sign up to RS cloud without CC details
15:17:52 <matel> So if that's a dependency, I need to find someone with a cc.
15:17:57 <BobBall> pretty sure of that
15:18:09 <matel> We need to find a company card in this case.
15:18:12 <johnthetubaguy1> yeah, you will need a credit card, its an anti-faud thing
15:18:15 <johnthetubaguy1> fraud
15:18:29 <johnthetubaguy1> well I will leave that with you
15:18:37 <matel> Okay, that will delay things I guess, but we'll find it out.
15:18:37 <BobBall> well perhaps - if my acc can be extended to have more than 6 months of free credit - we can use that.  John?  Any chance?
15:18:40 <BobBall> or should I talk to Ant?
15:19:00 <johnthetubaguy1> well you can ask, let me make an email thread
15:19:27 <johnthetubaguy1> #action help sort out an RS cloud account for matel
15:19:44 <matel> Thanks, in the meanwhile I will sync up with his work.
15:19:54 <johnthetubaguy1> so where are we now?
15:19:58 <johnthetubaguy1> what is left to do?
15:20:20 <johnthetubaguy1> what is the preferred route?
15:20:41 <matel> At the moment I am working on a document, and my recommendation is to use the RS cloud and the infrastructure
15:21:06 <matel> But I need to sync up, and understand the steps required.
15:21:16 <matel> nested virt.
15:21:27 <matel> In short: no decision made yet.
15:21:41 <matel> I was just communicating my personal view.
15:22:05 <matel> Spoke with dan
15:22:27 <matel> And we think that TripleO is not there yet to provide us the thing that is required by nova.
15:22:30 <johnthetubaguy1> well, we could run xenserver-core inside a rackspace performance flavor VM, with nova-compute running in dom0, running tempest tests, kicked off by devstack
15:22:53 <johnthetubaguy1> yes, triple0 is happening, but I don't see it reporting too much yet
15:23:27 <johnthetubaguy1> how far are we from the xenserver-core thing doing what we want
15:23:35 <matel> I agree - the thing you mentioned would be one way. That includes running devstack in dom0 and fixing xenserver-core.
15:23:40 <matel> and fixing full tempest
15:23:48 <johnthetubaguy1> noting that we only need a subset of tempest to work, for the initial phase
15:24:06 <matel> Yes, sure, a start with smoke I think will be fine.
15:24:13 <matel> And we're already passing them
15:24:20 <johnthetubaguy1> at the summit, it was accepted that some of tempest would be good, but just smoke was probably too little
15:24:31 <johnthetubaguy1> so lets just turn off the bits of full that are failing
15:24:36 <matel> Sure.
15:24:50 <johnthetubaguy1> OK, so I think we should just go for that
15:24:54 <johnthetubaguy1> its a good starting point
15:25:07 <matel> So my plan is to discover if the nested virt is working at all.
15:25:10 <johnthetubaguy1> when we have that, I will try get the Rackspace test suite running up there too
15:25:17 <johnthetubaguy1> I thought bob got that working?
15:25:28 * johnthetubaguy1 looks at BobBall
15:25:36 <matel> Yes, Bob got it working, but it involves several manual steps afaik.
15:25:40 <BobBall> for XenServer yes
15:25:50 <johnthetubaguy1> OK, so not tried xenserver-core?
15:25:58 <BobBall> and it was highly manual because RS cloud depends on xenstore for IP address
15:26:08 <BobBall> xenserver-core doesn't work yet in that scenario
15:26:13 <BobBall> don't know if it can be made to work
15:26:14 <johnthetubaguy1> why is that?
15:26:17 <matel> If it's manual, it's not working.
15:26:25 <BobBall> we need the kernel to disable the Xen bus on boot
15:26:33 <BobBall> but the config option to disable it didn't work when I tried it
15:26:46 <johnthetubaguy1> hmm, odd
15:26:50 <BobBall> not certain that the syntax / positioning was right - but it's far from clear that it'll work
15:26:57 <BobBall> without that config option, the kernel upgrades to PV
15:27:09 <johnthetubaguy1> ah, I see
15:27:13 <BobBall> or - more to the point - even when running in HVM mode it'll detect it's running under xen and unplug the non-PV devices
15:27:20 <matel> If the nested virt does not work, we are dead.
15:27:29 <BobBall> at which point we are left with no networking or disk, because the PV devices can't come up with no xenstore to the outside
15:27:38 <johnthetubaguy1> indeed, but doesn't sound like we have tried too hard just yet
15:27:47 <johnthetubaguy1> ah
15:27:52 <johnthetubaguy1> so we don't have xenstore?
15:28:04 <johnthetubaguy1> I thought you said that was working?
15:28:04 <BobBall> It might work if we can figure out how to set it
15:28:10 <BobBall> I really don't want to recompile the kernel :(
15:28:15 <johnthetubaguy1> sure
15:28:17 <BobBall> xenstore can never work with nested xen
15:28:27 <johnthetubaguy1> right, thats where I was confused before
15:28:36 <matel> I think XenServer needs to learn how to become a good guest!
15:28:39 <BobBall> I've certainly never said it was working :P
15:28:49 <johnthetubaguy1> I thought you said xenstore was working, I guess thats because it was in PV?
15:28:57 <BobBall> XenServer can be a guest - that has been working - but it can't dynamically get an IP
15:29:00 <BobBall> no
15:29:08 <BobBall> can't boot Xen as PV
15:29:15 <BobBall> if it's PV then it's only booting the kernel
15:29:16 <johnthetubaguy1> sure, I agree with that
15:29:17 <BobBall> and not Xen
15:29:28 <BobBall> so it doesn't apply
15:29:37 <BobBall> I mean it's physically not possible :)
15:29:54 <johnthetubaguy1> sure, I think we are talk a little cross purposes
15:30:02 <johnthetubaguy1> so if we do XenServer as a guest VM
15:30:11 <johnthetubaguy1> we still hit the needing the IP address issue?
15:30:36 <BobBall> We have two options:
15:30:41 <johnthetubaguy1> OK...
15:31:00 <BobBall> 1) Base image is XenServer (or xenserver-core).  Would need config drive or another way to get an IP address automatically.
15:31:15 <johnthetubaguy1> I should be able to sort out the config drive thing
15:31:21 <BobBall> 2) Base image is CentOS and we install xenserver-core on top, using the static IP address CentOS got from xenstore before upgrading
15:32:03 <johnthetubaguy1> oh I see, thats how that worked
15:32:07 <johnthetubaguy1> I like (2)
15:32:25 <johnthetubaguy1> but then it will take too long with that reboot
15:32:26 <BobBall> It would be nice, but it is far less certain
15:32:27 <matel> Is it an HVM centos?
15:32:28 <BobBall> and less stable
15:32:48 <johnthetubaguy1> yeah, there is an option (3)
15:33:10 <matel> I think these things could be summarized into a proper table to avoid future missunderstandings.
15:33:20 <BobBall> Yes - so option 2 would need us to prepare the image and convert it to HVM before installing xenserver-core
15:33:30 <BobBall> Was that the sound of a volunteer Mate?
15:33:46 <johnthetubaguy1> yeah, I need to understand the zuul image creation system
15:33:56 <BobBall> There isn't really one
15:34:00 <BobBall> it uses the images from the cloud
15:34:06 <BobBall> runs a prepare script on them to add them to the node pool
15:34:09 <BobBall> then it pulls from the node pool
15:34:14 <johnthetubaguy1> I thought the re-created an image every evening, then get some of them started "hot" and ready for code, then use them when required
15:34:15 <BobBall> we can do anything we like in that prepare script
15:34:32 <johnthetubaguy1> ah, OK
15:34:35 <johnthetubaguy1> gotcha
15:34:46 <johnthetubaguy1> so that makes (2) possible in the prepare scrip
15:34:47 <johnthetubaguy1> t
15:34:49 <BobBall> but yeah, it can't take too long
15:34:50 <BobBall> indeed
15:34:56 <matel> And how much time do we have in the prepare script?
15:35:00 <BobBall> or - at least - that's my understanding
15:35:04 <BobBall> not sure it's limited mate
15:35:14 <johnthetubaguy1> well, they start them up and add to the pool
15:35:24 <johnthetubaguy1> then the start time is when they get pulled out the pool right?
15:35:43 <johnthetubaguy1> we can skip exercises, and just do tempest (obviously) which saves some time
15:35:44 <BobBall> if we've got a good argument for extending any timeouts I'm sure the check jobs will accomodate
15:35:48 <matel> Okay, so as a first step, why don't we have a zuul job, with an empty prepare script?
15:35:50 <BobBall> unless it's the actual run time
15:36:03 <BobBall> First step should be to prove the difficult bit :)
15:36:11 <matel> That's not good
15:36:27 <johnthetubaguy1> yeah, first bit is get xenserver-core running in a VM
15:36:29 <BobBall> actual run time might need more discussions :)
15:36:37 <matel> I think, as the end result is a zuul job, you can demonstrate the results, if you have the frontend.
15:36:43 <BobBall> don't assume it's going to be xenserver-core - I think that's much riskier
15:37:09 <johnthetubaguy1> OK, but its more changeable
15:37:12 <matel> I am worried about the way we approach this.
15:37:20 <BobBall> which is a bad thing for the OpenStack team
15:37:22 <johnthetubaguy1> me too
15:37:37 <matel> I want to see the empty zuul jobs running.
15:37:38 <johnthetubaguy1> Can we just get tempest passing inside a VM?
15:37:48 <BobBall> Why mate?
15:37:52 <BobBall> What do you mean by an empty job?
15:37:57 <matel> Because that's how you deliver the things.
15:38:19 <johnthetubaguy1> yeah, zuul can be consisdered a known thing, I would love to prove the hard thing
15:38:25 <matel> I want to see things triggered by zuul, and modify things to give sensible results.
15:38:29 <johnthetubaguy1> but we could do this is parrallel
15:38:38 <BobBall> It's useless unless it's setting up a XenServer in a way that we're happy has a chance of passing things
15:38:43 <johnthetubaguy1> people do lots of crazy modifications to zuul already
15:38:58 <johnthetubaguy1> +1 we need a VM with tempest passing
15:39:13 <matel> I would do the zuul first, at least that's my way of delivering things.
15:39:13 <johnthetubaguy1> I care much less about what version of XenAPI is running
15:39:35 <johnthetubaguy1> we are not at the delivery phase, we are at the, could it work phase
15:39:40 <matel> The key thing here is to deliver something _VISIBLE_
15:39:41 <johnthetubaguy1> if it takes 2hours to do full temepst
15:39:50 <johnthetubaguy1> we can drop it on the floor
15:39:57 <BobBall> perhaps I'm mis-understanding what you want the zuul to do Mate
15:39:58 <johnthetubaguy1> and add tempest into smokestack
15:40:01 <BobBall> would it have anything to do with XenAPI?
15:40:18 <BobBall> initially*
15:40:31 <matel> First runs would do nothing, but then we would be able to develop the system by amending the scripts.
15:40:48 <BobBall> ok - yes, in which case I think that's the wrong approach
15:40:53 <matel> So that we have feedback.
15:40:58 <BobBall> because that's the bit we're more certain about how it would work
15:41:07 <johnthetubaguy1> yeah, I think I see what you mean matel, but we need to prove its worth trying first right, else thats wasted effort?
15:41:49 <johnthetubaguy1> anyways, we can do this in parallel if you want
15:41:51 <matel> What I am worried about is the progress of this task. I want to have visibility, and not relying on people saying "it works"
15:42:17 <matel> For me zuul is unknown, nested virt is unknown
15:42:23 <matel> everything is unknown.
15:42:31 <BobBall> We don't know that we'll have a solution to nested virt
15:42:33 <matel> And on these situations, you want to see something.
15:42:43 <BobBall> but the solution to the Zuul end is definitely feasible
15:43:04 <johnthetubaguy1> +1 don't worry about zuul
15:43:05 <BobBall> an empty job in Zuul makes things known, absolutely, but it doesn't give any visibility - because it wouldn't be doing anything useful
15:43:43 <johnthetubaguy1> so here is my view...
15:43:50 <matel> Maybe you missunderstood my intentions, but we could speak about it later, maybe what I want is not possible in this framework.
15:44:01 <johnthetubaguy1> 1) we need tempest to run under an hour
15:44:07 <matel> define tempest
15:44:14 <matel> define machines
15:44:22 <matel> Are we talking about the perf flavour?
15:44:31 <johnthetubaguy1> tempest full, but with a few tests missing if we want
15:44:41 <johnthetubaguy1> 2) I don't care where that runs, if it works
15:44:47 <johnthetubaguy1> 3) I don't care who runs it
15:44:52 <matel> Okay, it's taking 2 hours on phy machines, but they might be slower than perf.
15:45:02 <johnthetubaguy1> 4) the easiest runner is zuul, but right now it only talks to the cloud
15:45:14 <johnthetubaguy1> 5) we need to prove its fast enough in the cloud, i.e. nested virt
15:45:37 <johnthetubaguy1> 6) we need to prove we can automate the creation of that, I am happy to add a few little hooks to make that possible
15:45:40 <BobBall> Is the 2 hours running through tox?
15:45:46 <johnthetubaguy1> 7) we can wire that into zuull
15:46:02 <johnthetubaguy1> 2 hours is really really bad
15:46:28 <BobBall> matel? is the 2 hours using tox?
15:46:41 <matel> serial tempest afaik
15:46:45 <BobBall> ok
15:46:49 <BobBall> good
15:46:50 <matel> s/tempest/nose/g
15:46:55 <johnthetubaguy1> well, thats probably the issue
15:47:11 <johnthetubaguy1> so step 1, maybe, can we try tox on the physical machines?
15:47:20 <matel> Using parallel execution = loads of failures.
15:47:22 <BobBall> nah - let's go straight to the cloud
15:47:36 <johnthetubaguy1> well, we can always just do smoke I guess
15:47:54 <johnthetubaguy1> I need to improve build times anyways, so I can help optimize that
15:48:02 <BobBall> indeed.  Parallel is great if we can get it working, but if not, we need it not on local machine
15:48:22 <matel> Ran 175 tests in 521.146s
15:48:30 <johnthetubaguy1> ouch
15:49:09 <matel> I don't quite understand why do we need to run these expensive tests to test the driver...
15:49:21 <matel> but that's another question.
15:49:41 <johnthetubaguy1> because its what runs fast everywhere else, they are functional tests that prove the whole thing works right?
15:49:54 <BobBall> Let's figure out what's possible to do first before we focus too much on the speed of the full suite.
15:50:01 <johnthetubaguy1> we have some faster ones than run in well under 15 mins I think, but thats a different thing
15:50:07 <matel> Because we don't have proper tests for the drivers righ?
15:50:13 <BobBall> We can look for speedups or reduce the tests we run at another time
15:50:27 <johnthetubaguy1> nope, we do have OK tests for those, but we stil NEED tests with the whole stack
15:50:36 <johnthetubaguy1> but anyways
15:50:40 <matel> But that's the whole OS, not nova.
15:50:44 <johnthetubaguy1> lets focus on getting smoke tests running
15:51:13 <matel> Anyhow, I have seen, that OpenStack community is keen on burning CPU time, it makes everyone happy and proud... :-)
15:51:17 <johnthetubaguy1> matel: before when we didn't include the other bits it all fell apart, its not like we run swift mind
15:51:49 <matel> Okay, sorry for that.
15:51:53 <matel> Be constructive.
15:51:53 <johnthetubaguy1> matel: but if you have ideas on speeding that up, certainly suggest them
15:52:00 <johnthetubaguy1> anyways
15:52:05 <johnthetubaguy1> so the goal...
15:52:20 <johnthetubaguy1> tempest (smoke to start with) running in a cloud VM
15:52:40 <BobBall> Hopefully
15:52:41 <johnthetubaguy1> 2) automate the creation of said VM in a script
15:53:03 <johnthetubaguy1> yeah, we have to just try it, and stop talking really
15:53:08 <johnthetubaguy1> who wants to do that?
15:53:35 <BobBall> Mate does
15:53:38 <matel> I don't have access to the RS cloud
15:53:48 <johnthetubaguy1> but bob does...
15:53:55 <matel> bob != mate
15:53:57 <BobBall> We can fix that short term
15:54:00 <matel> ok
15:54:03 <BobBall> I don't have a medium term solution
15:54:07 <johnthetubaguy1> OK, so let me come around tomorrow, and we can work on this?
15:54:08 <BobBall> that's what John is looking into
15:54:13 <matel> I can play with that, Bob can tell me what he has done so far.
15:54:28 <BobBall> not worth it yet john
15:54:34 <johnthetubaguy1> So, matel/BobBall do you want to try XenServer?
15:54:44 <johnthetubaguy1> I can go with xenserver-core?
15:54:52 <BobBall> Can't without config drive
15:55:01 <johnthetubaguy1> OK, so I should work on config drive?
15:55:10 <matel> John: I would don't care what is it, let's do a test drive, measure, and act
15:55:19 <BobBall> If you can push a way of an HVM guest with no xenstore to get an IP
15:55:19 <BobBall> yes
15:55:23 <BobBall> that would be _SUPER_ helpful
15:55:23 <johnthetubaguy1> #action johnthetubaguy1 to make sure config drive has useful ip addresses
15:55:32 <BobBall> in RS cloud
15:55:34 <BobBall> that's the key big
15:55:36 <BobBall> bit*
15:55:38 <johnthetubaguy1> yeah, I missed that bit
15:55:39 <johnthetubaguy1> lol
15:55:50 <BobBall> it's useless if it just works in nova somewhere and might get to RS cloud in 2015
15:55:51 <johnthetubaguy1> I have the patched merged for the OS case
15:55:53 <BobBall> :)
15:56:05 <johnthetubaguy1> yeah, its probably 2014 now, but I can try
15:56:08 <BobBall> also, it's the HVM guest with no xenstore thing too
15:56:24 <johnthetubaguy1> though config drive, yes
15:56:29 <BobBall> i.e. if config drive mounts as drive number 5 and required PV tools to mount it - it's useless
15:56:40 <johnthetubaguy1> its device 4, I made sure of that
15:56:47 <BobBall> that's good
15:56:54 <johnthetubaguy1> its not an accident
15:58:11 <BobBall> we're out of time
15:58:12 <matel> Okay, so the message is that Mate/Bob will look at the nested VM, report issues to John, and John will help with those issues.
15:58:19 <johnthetubaguy1> https://github.com/openstack/nova/commit/b1445e7e84b720ac232541ef866fbe7a59faeaf8
15:58:33 <johnthetubaguy1> its #3
15:58:45 <johnthetubaguy1> sounds good
15:58:58 <johnthetubaguy1> who whats to take the meeting next week?
15:59:00 <johnthetubaguy1> I am on holiday
15:59:10 <matel> We'll just skip it I guess.
15:59:11 <johnthetubaguy1> or shall we skip it?
15:59:11 <BobBall> Well we'll skip it then
15:59:15 <johnthetubaguy1> cool
15:59:24 <johnthetubaguy1> see you in two weeks
15:59:26 <johnthetubaguy1> thanks all
15:59:29 <BobBall> let me finish it?
15:59:30 <matel> Have a good holida
15:59:33 <matel> Have a good holiday
15:59:35 <matel> No
15:59:36 <johnthetubaguy1> BobBall: sure
15:59:38 <BobBall> #endmeeting
15:59:40 <johnthetubaguy1> mate: thank you :)
15:59:43 <matel> Hah
15:59:44 <BobBall> poo - didn't work
15:59:45 <johnthetubaguy1> wait for it...
15:59:47 <matel> hah
15:59:49 <matel> poor Bob.
15:59:50 <BobBall> wasn't that > 60 minutes?
15:59:51 <johnthetubaguy1> a message comes up
15:59:52 <matel> Crying.
15:59:53 <johnthetubaguy1> nope
16:00:09 <matel> Have you tried to turn it off and on?
16:00:22 <BobBall> #endmeeting