15:02:38 <johnthetubaguy1> #startmeeting XenAPI
15:02:39 <openstack> Meeting started Wed Jul  3 15:02:38 2013 UTC.  The chair is johnthetubaguy1. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:42 <openstack> The meeting name has been set to 'xenapi'
15:02:49 <johnthetubaguy1> Hi all
15:02:55 <johnthetubaguy1> who is here for the meeting today?
15:03:16 <euanh> Euan here
15:04:20 <BobBall> Bob here
15:04:44 <BobBall> Mate coming
15:04:44 <johnthetubaguy1> So I was wanting to check progress towards H-2
15:04:57 <johnthetubaguy1> so lets go to the blueprints
15:05:02 <johnthetubaguy1> #topic blueprints
15:05:14 <johnthetubaguy1> so has anyone got anything to report
15:05:21 <johnthetubaguy1> H2 and H3
15:05:25 <BobBall> nope - didn't think we had blueprints in H2
15:06:08 <BobBall> in terms of H3 we're not convinced the event reporting is high enough priority atm
15:06:13 <johnthetubaguy1> hmm, I do I guess
15:06:13 <matel> What was the etherpad address used during the summit?
15:06:25 <johnthetubaguy1> can't remember right now
15:06:33 <matel> #link https://etherpad.openstack.org/HavanaXenAPIRoadmap
15:06:59 <johnthetubaguy1> lol, just found that too
15:07:06 <matel> So I will look at this #link https://blueprints.launchpad.net/nova/+spec/xenapi-volume-drivers
15:07:30 <matel> I need to look at what the cinder guys are doing around brick.
15:07:43 <johnthetubaguy1> ah, yes, good point
15:07:51 <johnthetubaguy1> that is not targeted for H right now
15:07:55 <BobBall> I was tracking the pci pass through blueprint - it's just landing ATM which is great, and it's 95% hypervisor agnostic with only a few changes in the driver needed
15:08:20 <johnthetubaguy1> that sounds cool
15:08:27 <johnthetubaguy1> anything people activly working on for H2
15:08:33 <johnthetubaguy1> I guess the answer was no
15:08:39 <BobBall> Not in terms of the published blueprints no
15:09:16 <BobBall> When we get off the Blueprints topic I'm sure we can say what we have been doing :D
15:10:00 <matel> john, do you have any links for the brick work?
15:10:17 <johnthetubaguy1> afraid not, worth looking at cinder mins
15:10:26 <johnthetubaguy1> so I have some blueprints
15:10:28 <johnthetubaguy1> https://blueprints.launchpad.net/nova/+spec/xenapi-large-ephemeral-disk-support
15:10:38 <johnthetubaguy1> I have that pending review, I removed the config
15:10:56 <johnthetubaguy1> There was also this one:
15:10:58 <johnthetubaguy1> https://blueprints.launchpad.net/nova/+spec/xenapi-guest-agent-cloud-init-interop
15:11:14 <johnthetubaguy1> but I pushed that out to H3, it took a little while
15:11:59 <johnthetubaguy1> so reviews welcome on the first one
15:12:00 <BobBall> Well I cn have a look - I think that we like the 2TB disk one
15:12:05 <BobBall> yeah
15:12:12 <matel> I have some -1s in my bag.
15:12:14 <johnthetubaguy1> so, any more for blueprints?
15:12:23 <johnthetubaguy1> matel: hehe
15:12:25 <BobBall> it's hurting the nova review stats though!
15:12:29 <BobBall> 10 days!
15:12:43 <johnthetubaguy1> its really getting slow, the queue is huge
15:13:28 <matel> Does the size of the ques has something to do with the number of reviewers?
15:13:38 <matel> s/ques/queues/g
15:13:41 <johnthetubaguy1> a little bit
15:13:49 <johnthetubaguy1> but mostly just the number of patches added
15:14:01 <johnthetubaguy1> its the time many people start pushing their code
15:14:08 <matel> Okay, we are diverging.
15:14:12 <johnthetubaguy1> lots of v3 API stuff too
15:14:16 <johnthetubaguy1> indeed
15:14:39 <johnthetubaguy1> has anyone else got anything?
15:14:46 <johnthetubaguy1> jump to open discussion?
15:14:51 <matel> I updated the Quantum install wiki.
15:14:57 <matel> trying to keep it up to date.
15:15:11 <matel> We are looking at full tempest runs
15:15:13 <BobBall> Euan has fixed a bug.
15:15:18 <johnthetubaguy1> #topic Open Discussion
15:15:33 <BobBall> BFV tests are passing too Mate - don't forget that! good change right there
15:15:43 <BobBall> last gating test that wasn't apssing
15:15:45 <BobBall> passing*
15:15:52 <johnthetubaguy1> awesome
15:16:02 <johnthetubaguy1> some good work on tempest it seems
15:16:18 <johnthetubaguy1> any news on gateing work from NYC?
15:16:20 <BobBall> We found + fixed a stability problem with smokestack and XenServer
15:16:31 <matel> We are not touching tempest, we are just looking at what are the failures.
15:16:52 <johnthetubaguy1> sure, just wondering what the planned path is / timeline is
15:16:54 <BobBall> yeah - so the current plan is that someone (possibly Jim) will implement dependencies in zuul
15:17:13 <BobBall> so you can have a depends-on patch bringing in another patch for testing and merging
15:17:34 <BobBall> that's a pre-requisite for any packaging really as if a nova change needs a packaging change they need to be synchronised
15:18:04 <BobBall> The packaging isn't something we are going to gate on - but if we can get the dependency mnagement in then we can look at gating on smokestack test failures that are unrelated to packaging
15:18:07 <johnthetubaguy1> erm, I was thinking more XenAPI related
15:18:34 <matel> Ah, I have a question.
15:18:48 <BobBall> it comes round to XenAPI with smokestack being more resilient because it currently breaks when packaging changes are needed / merged
15:19:21 <BobBall> and giving us the option of only posting -ve reviews when we know it's a test failure and not a packaging issue
15:19:31 <BobBall> which is a big part of the issue with getting smokestack gating
15:19:32 <BobBall> yes Mate
15:19:36 <matel> Could you guys look at it? #link https://bugs.launchpad.net/nova/+bug/1196570
15:19:37 <uvirtbot> Launchpad bug 1196570 in nova "xenapi: pygrub running in domU" [Undecided,New]
15:20:00 <johnthetubaguy1> so, I thought we were looking at getting something other than smokestack gating?
15:20:05 <matel> So it's about having a disk image, and we would like to ask pygrub to decide if it is a PV or HVM guy
15:20:54 <matel> sorry guys, just finish off the discussion around testing, I did not want to be rude.
15:20:59 <johnthetubaguy1> matel: there is a bit of code that uses pygrub, thinking about it
15:21:19 <BobBall> We're also looking at the option of having a Xenserver-core VM with nova in dom0 running the tempest tests - but if the dependency thing is implemented, smokestack gating is an easy step forward
15:21:31 <matel> johnthetubaguy1: this is a code, my issue, that this code is assuming, that you have pygrub in domU
15:21:56 <matel> That means that you might end up with different pygrub versions in dom0 and domU - dodgy
15:22:14 <BobBall> only due to the rootwrap?  Why does it use pygrub in domU rather than dom0?
15:22:14 <johnthetubaguy1> matel: https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vm_utils.py#L1921
15:22:17 <matel> I would really want to run pygrub in dom0, or have a xapi extension....
15:22:47 <johnthetubaguy1> matel: its not code most people use, if they have good glance metadata, but yes, I get your point
15:22:50 <matel> johnthetubaguy1: yes, I am referring to that code.
15:23:15 <BobBall> That bit will be trivial to move to dom0 if we want to - it just attaches the VDI to the domu only to run pygrub so that can easily do it in dom0
15:23:25 <johnthetubaguy1> Personally, we should just default to HVM, and stop worrying about trying to detect it
15:23:45 <johnthetubaguy1> but I guess we can see what other people think
15:23:59 <matel> So in order to get some outcome from this discussion, who prefers which option? A) remove it B)delegate to dom0
15:24:09 <BobBall> HVM isn't supported for most guests :)
15:24:16 <BobBall> only windows is supported in HVM
15:24:31 <BobBall> B - delegate to dom0 or C - leave it if we have to...
15:24:41 <BobBall> to fix the bug, definitely delegate
15:24:51 <johnthetubaguy1> yeah, that works for me
15:25:00 <johnthetubaguy1> just wondering if we really need it
15:25:03 <matel> tbh, I like the remove.
15:25:16 <matel> although I originally did not think about it.
15:25:26 <johnthetubaguy1> its worth a mail to the list, see what people think
15:25:27 <BobBall> yes we must boot linux guests as PV if we want them to be supportable
15:25:27 <matel> That's my favourite code modification - delete.
15:25:37 <johnthetubaguy1> we are trying to get rid of auto detect
15:25:39 <matel> The best thing that could happen to code - get removed
15:25:48 <BobBall> therefore we must keep it or let something else specify it
15:25:50 <johnthetubaguy1> yeah, you can specify os type in glance, so its not like you can't choose
15:26:00 <BobBall> ok - if you can specify in glance then that's OK
15:26:09 <matel> I met with this code while i was booting from volume
15:26:18 <BobBall> So if an image in glance is PV then it'll boot PV I'm happy
15:26:32 <matel> The issue is that if you are booting from volume, the metadata might not be there.
15:26:36 <johnthetubaguy1> yeah, thats the fun one, but you can launch an image that specifis the block device mapping and the correct os type
15:26:47 <BobBall> we just can't boot _all_ guests as HVM and trust they will negotiate up (which is what I thought you were suggesting)
15:28:23 <matel> johnthetubaguy1: have you ever tried to do that?
15:28:37 <johnthetubaguy1> matel: no, actually, its quite a new feature
15:28:56 <matel> Okay, so Bob suggests to delegate this to dom0
15:29:03 <johnthetubaguy1> BobBall: I wasn't thinking they would negociate up, I was more thinking we need a better solution, guessing seems bad
15:29:16 <johnthetubaguy1> Yeah, we could try for that
15:29:36 <matel> Simplest change is removal.
15:29:52 <BobBall> hang on
15:29:54 <BobBall> wait wait wait
15:30:16 <BobBall> if we can typically rely on the metadata to determine if it should be PV or HVM then I'm happy with deleting the autodetect code
15:30:32 <johnthetubaguy1> yeah, just default to HVM for giggles
15:30:40 <BobBall> I know BFV currently doesn't have that metadata - but if that's a bug then we can still rely on metadata etc
15:30:55 <johnthetubaguy1> well, you can do BFV from a glance image
15:30:59 <johnthetubaguy1> then you get metadata
15:31:08 <johnthetubaguy1> same thing you need for external ramdisk and kernels
15:31:12 <matel> yes, so basically these are separate issues.
15:31:16 <BobBall> if we _can't_ reliably rely on the metadata then we need autodetect
15:31:30 <BobBall> (in dom0)
15:31:35 <johnthetubaguy1> hmm, well maybe
15:31:45 <matel> Question: do we want to autodetect if a given block device contains hvm vs pv stuff?
15:32:03 <johnthetubaguy1> maybe
15:32:30 <BobBall> I say no - if we need to detect the mode then we should have some form of metadata associated with the block device that says what it contains
15:32:58 <matel> Okay, so Bob votes for removal.
15:33:00 <BobBall> if the metadata route is typically the canonical source of information then that's what we should always use
15:33:02 <johnthetubaguy1> we have that in glance, to some extent
15:33:05 <BobBall> sorry for changing my vote.
15:33:26 <BobBall> but now I understand the problem better - and that we will still boot Linux guests as PV then I'm happy
15:33:27 <matel> I vote for removal, because I want to make the code happier.
15:33:53 <johnthetubaguy1> +1
15:34:10 <matel> Let's do it this way: I will submit a patch, and you can vote on the change.
15:34:11 <johnthetubaguy1> and bring it back if we need to, in a better way
15:34:21 <matel> in dom0
15:34:23 <johnthetubaguy1> yeah, the remove is a simple patch
15:34:28 <matel> yes, let's YAGNI
15:34:40 <BobBall> +
15:34:41 <BobBall> 7
15:34:45 <BobBall> +7 even
15:34:47 <matel> seven?
15:34:49 <BobBall> I don't think +1 is enough
15:35:16 <matel> Okay, expect a patch soon.
15:36:30 <matel> I am adding new items to the sprint backlog - my boss will love it.
15:36:39 <johnthetubaguy1> :)
15:36:44 <johnthetubaguy1> so we got anything else?
15:37:02 <matel> I fixed some minor bugs last week, but nothing worths mentioning.
15:37:22 <BobBall> I submitted a fix for snapshot reordering
15:37:29 <matel> Bad.
15:37:29 <BobBall> coalescing even
15:37:33 <matel> Ah.
15:37:39 <matel> Okay, missunderstood.
15:37:51 <matel> Could you link the change sir?
15:37:53 <BobBall> but it doesn't have a test yet and I think people want a test but I've been super busy on not being able to code :/
15:38:10 <BobBall> #link https://review.openstack.org/#/c/34528/ <-- Lonely changeset seeking review.
15:38:14 <matel> Untested code is broken by desgin.
15:38:19 <BobBall> it's a trivial change
15:38:22 <BobBall> yeah yeah :)
15:38:41 <BobBall> I'm happy to try and add a test (although I'm not quite sure how to test this one!)
15:39:05 <BobBall> it's all about the order in which things get called so I'll have to think about it
15:39:26 <matel> that's a huge function, good luck.
15:39:28 <BobBall> and my head's been elsewhere
15:39:32 <BobBall> indeed
15:39:44 <johnthetubaguy1> no +2 without a test :)
15:39:45 <BobBall> perhaps I should delegate the writing of the test...
15:40:06 <johnthetubaguy1> unless its "already covered"
15:40:09 <matel> 1000 story points
15:40:14 <BobBall> you're a mean man!
15:40:16 <BobBall> yes
15:40:21 <BobBall> it's "already covered"...
15:40:23 <matel> I bet the reviewers are running coverage.
15:40:24 <BobBall> definitely
15:40:36 <johnthetubaguy1> … yeah...
15:40:39 <BobBall> the code is being exercised so coverage wouldn't find it
15:40:55 <matel> Okay, let's stop it.
15:41:10 <BobBall> the problem is that both sets of code are fully exercised but in a different order :D
15:41:27 <matel> The problem, is that the code is not really structured well
15:41:29 <BobBall> can I apply for a "too difficult to test" exception?
15:41:41 <matel> So it's not Bob's fault.
15:41:51 <BobBall> yeah!
15:41:53 <matel> I can take the job of testing it.
15:42:11 <BobBall> I was kidding mate - I'm not the type to make others test my work
15:42:11 <matel> reverse tdd
15:42:15 <johnthetubaguy1> if the ordering is a problem, lets keep it right
15:42:19 <BobBall> I may ask for your advice though
15:42:45 <matel> we might want to extract something sensible.
15:42:48 <matel> we'll see.
15:42:53 <matel> take it offline
15:42:56 <BobBall> I have an idea on how to test it
15:43:13 <BobBall> just no time this last week
15:43:22 <matel> Okay, anything else?
15:43:33 <BobBall> not from me
15:43:41 <matel> I'm done as well.
15:43:48 <johnthetubaguy1> nothing from me
15:43:48 <matel> Keen to get back to my terminal.
15:43:51 <johnthetubaguy1> we all good?
15:43:55 <BobBall> go for it Mate
15:43:55 <matel> sure
15:44:00 <BobBall> there's a test waiting for you to write.
15:44:09 <matel> yes
15:44:18 <matel> And I can remove some lines in exchange
15:44:49 <BobBall> Good pln.
15:44:52 <johnthetubaguy1> we all done?
15:45:12 <matel> ["sure"] * 1000
15:46:06 <johnthetubaguy1> #endmeeting