15:00:17 <johnthetubaguy1> #startmeeting XenAPI
15:00:18 <openstack> Meeting started Wed Jun 19 15:00:17 2013 UTC.  The chair is johnthetubaguy1. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:21 <openstack> The meeting name has been set to 'xenapi'
15:00:41 <johnthetubaguy> so, who is here for the meeting today?
15:00:51 <johnthetubaguy> also, got anything for the agenda?
15:01:09 <matel> I am here.
15:01:30 <johnthetubaguy> I was going ask about gating trunk progress, and that is about all
15:01:51 <matel> Okay, you need bob.
15:02:17 <matel> What I wanted to ask, is a review on this: #link https://review.openstack.org/#/c/33424/
15:02:22 <johnthetubaguy> yeah, spoke to him earlier, think he is attending the bootcap
15:02:49 <johnthetubaguy> matel: sure, I spotted that the other day :)
15:03:00 <matel> I'm working from HUN this week, and next, so I can't just shout for Bob.
15:03:39 <johnthetubaguy> gotcha
15:03:47 <matel> And have you seen the quantum blog entry? #link http://blogs.citrix.com/2013/06/14/openstack-networking-quantum-on-xenserver-from-notworking-to-networking/
15:03:52 <BobBall> I'm here too
15:04:00 <BobBall> sorry - was watching the wrong window
15:04:00 <matel> Oh, we have a Bob.
15:04:01 <BobBall> :D
15:04:12 <BobBall> was wondering why the meeting hand't started...
15:04:13 <BobBall> hadn't*
15:04:14 <johnthetubaguy> so, just wondering if anyone has anything for the agenda
15:04:18 <matel> John is asking about gating.
15:04:32 <johnthetubaguy> #topic OpenDiscussion
15:04:35 <BobBall> I'd like to talk about snapshot_attached_here
15:04:40 <johnthetubaguy> OK
15:04:45 <BobBall> but we can talk about gating first
15:04:49 <matel> link in a line of code.
15:05:28 <johnthetubaguy> I think gating is OK, you are going away to NY to ask the people there about things
15:05:28 <BobBall> 1 sec
15:05:50 <johnthetubaguy> fireaway about snapshot_attached_here, although I might not remember everything
15:05:56 <BobBall> https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vm_utils.py#L649
15:06:00 <BobBall> #link https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vm_utils.py#L649
15:06:13 <matel> oK
15:06:16 <BobBall> so - yes - snapshot_Attached_here
15:06:19 <BobBall> doesn't attach a snapshot
15:06:24 <BobBall> from what I can tell... :)
15:06:38 <BobBall> it _creates_ a snapshot
15:06:52 <BobBall> which is deleted at the end of the function (after yielding it to the caller)
15:07:01 <BobBall> but nothing is attached in the context - correct?
15:07:12 <johnthetubaguy> yeah, maybe… yuck
15:07:17 <johnthetubaguy> never used it myself
15:07:22 <johnthetubaguy> used vdi_attached_here
15:07:40 <BobBall> well that does do an attach
15:07:43 <BobBall> so that makes sense
15:07:50 <johnthetubaguy> indeed
15:08:02 <BobBall> but snapshot_attached_here doesn't AFAICT - agreed?
15:08:15 <BobBall> If so, I'll rename it shortly
15:08:33 <BobBall> The next thing I want to talk abnout is...
15:08:33 <johnthetubaguy> one sec
15:08:36 <BobBall> #link https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vm_utils.py#L1861
15:08:41 <johnthetubaguy> just looking at the change that introduced it
15:10:40 <matel> what does this function do...
15:10:43 <BobBall> that history is a mess
15:10:49 <johnthetubaguy> BobBall: https://github.com/openstack/nova/commit/665516f72402eac00455517446716cd7d43323db maybe with_tempory_snapshot?
15:10:54 <BobBall> yes
15:10:58 <BobBall> that was what I was going to rename it to
15:11:05 <johnthetubaguy> cool
15:11:07 <johnthetubaguy> sounds good
15:11:18 <johnthetubaguy> so… _wait_for_vhd_coalesce
15:11:27 <BobBall> yes
15:11:31 <BobBall> wait for vhd coalesce...
15:11:38 <matel> so.
15:11:38 <BobBall> I don't understand it
15:11:52 <BobBall> it seems too complicated and I want to simplify it
15:11:55 <matel> the main purpose seems to be, that you'll have a snapshot in the context.
15:12:08 <BobBall> yes Mate - that's right
15:12:20 <BobBall> and the 0'th uuid you get back is the snapshot uuid
15:12:22 <BobBall> but that's all it does
15:12:30 <matel> Name proposals?
15:12:46 <BobBall> temporary_snapshot so you can have with temporary_snapshot
15:12:49 <johnthetubaguy> well never touched that myself, it looks a bit dodgy, I think its trying to ensure the chain is as small as possible I guess
15:13:21 <johnthetubaguy> Oh, OK, sorry, we going back to that other code
15:13:25 <BobBall> yes, that's what it's doing, but it's not doing it right (IMO) - if we want to ensure the chain is as small as possible then perhaps we should link through to the GC and ask when it's finished collecting on that SR
15:13:50 <BobBall> it's easy to have a plugin that finds out if GC is running on the SR (and trigger it if not)
15:14:07 <BobBall> then we can have a check that the state is something we can manage - which is what we should be really testing...
15:14:10 <johnthetubaguy> BobBall: yeah, we really should, its just using the public stuff and looping I guess
15:14:24 <BobBall> I don't like the assumptions in the function
15:14:27 <BobBall> no, no looping...
15:14:41 <BobBall> it's dodgy because it's asking for a VDI ref _and_ an original parent UUID
15:14:57 <BobBall> so there is an in-built assumption that you know what will be coalesced
15:15:33 <johnthetubaguy> erm, I supose
15:16:11 <BobBall> which is wrong isn't it?
15:16:13 <johnthetubaguy> from memory its to help tidy up after migration and snapshot uploads
15:16:26 <johnthetubaguy> so, feel free to go wild
15:16:46 <BobBall> ok.  In terms of the wait condition, would there be objections to waiting on that SR for all GC to be completed?
15:17:02 <BobBall> that may include other VDIs on the same SR, which is a pain
15:17:18 <BobBall> but I'm not sure it wouldn't anyway (i.e. does the DB really reflect the right state mid-GC)
15:17:37 <johnthetubaguy> yeah, I don't think it makes any material difference, sadly
15:17:57 <johnthetubaguy> it would be good to know the expected coallese has actually happened though
15:18:09 <johnthetubaguy> incase the GC decided not to bother, for whatever reason
15:18:35 <BobBall> indeed
15:19:25 <johnthetubaguy> well, that all sounds like something worth doing
15:19:35 <johnthetubaguy> some good code tidies
15:19:47 <BobBall> it's part of making EXT3 leaf coalesce work
15:20:14 <johnthetubaguy> ah, OK, sounds good
15:20:19 <BobBall> I know I could just fix the resize up case but I was trying to test it as I was going and there isn't a sensible way to do that atm
15:20:20 <BobBall> :)
15:20:28 <johnthetubaguy> I had talking direct to the GC on my TODO list
15:20:29 <BobBall> or if there is I haven't figured it out yet
15:20:38 <johnthetubaguy> resize up case?
15:20:46 <johnthetubaguy> ah yes
15:20:56 <johnthetubaguy> the leaf VHD bigger than parent?
15:21:07 <BobBall> yeah - if you do a resize up it uses snapshot_attached_here then assumes it continues to exist after it is deleted
15:21:31 <johnthetubaguy> hmm, that sounds bad
15:21:44 <johnthetubaguy> resize up works today, so is it just an edge case that fails?
15:21:46 <BobBall> so I was trying to prove that was the case by using wait_for_vhd_coalesce to GC (or fail to GC) the snapshot down into one VDI
15:22:00 <BobBall> no, it doesn't fail - XS doesn't support leaf coalesce for EXT3 atm
15:22:04 <BobBall> so the case never happens
15:22:13 <BobBall> because the snapshot is never coalesced down
15:22:19 <johnthetubaguy> ah, I see
15:22:24 <BobBall> however it's trivial to enable it and we want to enable it but not break openstack :)
15:22:39 <johnthetubaguy> its only the non-leaf that are coalesced...
15:22:44 <BobBall> correct
15:22:59 <johnthetubaguy> OK, yeah, got confused with other things
15:23:04 <BobBall> so after a snapshot you are currently guaranteed to have one base and one snap
15:23:09 <BobBall> I want to break that guarantee :)
15:23:19 <johnthetubaguy> cool
15:23:26 <johnthetubaguy> makes sense
15:23:55 <BobBall> grand
15:24:03 <BobBall> ok - I'll just plough on with what I'm doing then and put something up
15:24:21 <BobBall> I'll raise a bug too - because I consinder this a bug against XS trunk
15:24:31 <johnthetubaguy> sounds good
15:24:35 <johnthetubaguy> you mean OS trunk?
15:24:36 <BobBall> i.e. the OS code is making assumptions that aren't necessarily true
15:24:42 <BobBall> no - OS running against XS turnk
15:24:45 <BobBall> trunk*
15:24:53 <johnthetubaguy> ah, I see now
15:25:25 <johnthetubaguy> OS fails on trunk because the orig has gone away
15:25:25 <BobBall> Some fun news - euanh is going to look at a live migration bug this week!
15:25:36 <johnthetubaguy> which bug?
15:25:40 <BobBall> first OS bug he'll be fixing for us :)
15:25:54 <johnthetubaguy> got a link?
15:26:17 <BobBall> Maybe https://bugs.launchpad.net/nova/+bug/1073306 or https://bugs.launchpad.net/nova/+bug/1074087 depending on how things go
15:26:18 <uvirtbot> Launchpad bug 1073306 in nova "xenapi migrations don't apply security group filters" [Medium,Triaged]
15:26:58 <johnthetubaguy> ah cool
15:27:22 <johnthetubaguy> of course, don't forget to nick the bug when he starts looking
15:27:45 <johnthetubaguy> can you tell rackspace doesn't expose security groups yet...
15:27:45 <BobBall> indeed.  Currently fighting with devstack
15:28:03 <johnthetubaguy> ah, a new tester for matel changes :)
15:28:30 <BobBall> well more fighting with it expecting to install it's own Ubuntu VM which Mate isn't changing...
15:28:38 <matel> My job is to make Bob's life harder
15:29:17 <BobBall> You're doing great at that Mate!
15:29:23 <matel> Thanks.
15:29:48 <johnthetubaguy> hmm, OK
15:29:49 <matel> So, I think you need the flat_network_bridge
15:29:56 <johnthetubaguy> anyways
15:30:04 <johnthetubaguy> any more to discuss?
15:30:24 <matel> Just put FLAT_NETWORK_BRIDGE in your localrc with the right value.
15:30:33 <matel> I am done,
15:30:34 <BobBall> no, I think that's it from me!
15:31:12 <johnthetubaguy> cool
15:31:15 <johnthetubaguy> #endmeeting
15:31:18 <johnthetubaguy> thanks all
15:31:29 <johnthetubaguy1> #endmeeting