Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-02
15:53:18 jaypipes efried: it's just I added a shit-load of new tests in the traits patches and would rather add separate patches for ever-more-complicated test scenarios.
15:54:52 kashyap mdbooth: A question - During an instance boot, Glance image is copied to the local host image cache. Then, Nova creates a qcow2 overlay with this copied image as a backing file. Now, does anything modify this backing file?
15:55:18 kashyap (Over the course of an instance life cycle, i.e.)
15:56:14 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: provide vGPU inventory in compute node https://review.openstack.org/516217
15:56:31 mdbooth kashyap: It can be deleted, but apart from that it is immutable.
15:57:35 kashyap mdbooth: Thank you. DanPB is proposing something interesting on qemu-devel list in context of OpenStack, you might want to read it if you're bored on your plane :-) https://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg00165.html
16:03:02 mdbooth kashyap: I've been thinking of that exact architecture for a while myself, but I didn't know what the intermediate qemu-nbd bit would consist of. Sounds extremely interesting.
16:03:38 kashyap mdbooth: Yeah, very interesting
16:04:07 kashyap Last week, I also saw something intersting: globally distributed qcow2 chains
16:04:59 kashyap mdbooth: I'm about to ask Dan on that thread, in relation to his second ascii diagram, why does he say: "The problem is that many VMs are wanting to use cache-disk1.qcow2 as
16:05:03 kashyap their disk's backing file"
16:05:12 kashyap And a couple of other questions
16:05:22 mdbooth kashyap: What's the question?
16:06:07 kashyap mdbooth: From that second "diagram", all those VMs wanting to use 'cache-disk1.qcow2' as their backing file _aren't_ trying to modify the backing file, are they?
16:06:22 kashyap If yes, what _are_ they trying to write into it?
16:06:24 mdbooth kashyap: Yes, they are
16:06:41 kashyap Please explain
16:06:42 mdbooth The intermediate backing file is essentially a COR disk
16:07:17 mdbooth So every time the upper layer makes a read request, the intermediate layer also makes a read request to the bottom layer, then *writes* it to itself.
16:07:29 mdbooth If all VMs are doing this, that's multiple writers.
16:07:32 kashyap mdbooth: Hang on, just to ensure we're talking about the same section, I'll get a pastebin of what I'm referring to:
16:07:51 kashyap I'm referring to this section: http://paste.openstack.org/show/625365/
16:08:13 mdbooth Yes
16:08:30 mdbooth The cache disk is a cache, but it's being continuously updated from its own backing store
16:08:35 mdbooth The remote backing store in glance
16:08:37 kashyap mdbooth: I'll Cc you on that thread, and you can respond there, for clarity's sake
16:08:43 kashyap Is it okay?
16:08:56 mdbooth Sure.
16:09:39 mdbooth Anyway, if your backing store is COR, it means you write to it every time you make a read request for something it hasn't got locally.
16:09:59 mdbooth It has to fetch it and store it, and the store is a write operation.
16:10:04 kashyap Yeah, I realize COR -- everytime you read a cluster from the backing file, you write that locally, to avoid reading it again
16:10:14 kashyap Ah, right.
16:10:30 mdbooth Yep, but in this model the backing file itself is COR, not just the upper layer.
16:10:52 mdbooth So although the backing file may be presented to the upper layer as RO, it's actually still being updated by qemu.
16:12:13 kashyap mdbooth: Hang on, _is_ there an upper layer, in this scenario? There's only two images here: "cache-disk1.qcow2" is the local backing file (copied from 'master-disk1.qcow2' from Glance)
16:12:22 kashyap And 'vm-a-disk1.qcow2' is the Nova instance disk.
16:12:51 openstackgerrit Eric Fried proposed openstack/nova master: RequestGroup class for placement & consumers https://review.openstack.org/517364
16:12:58 efried jaypipes ^
16:13:16 efried jaypipes If you could take a quick look to make sure no huge changes are needed, I'll rebase everything else on top.
16:13:38 jaypipes efried: soon as I am done with n-r-p rebase/fixes. should be five mins
16:13:45 efried rgr
16:13:56 efried mriedem also ^
16:15:37 mriedem on my day before leaving for sydney, i'm not going to start tackling the granular request stuff
16:16:33 openstackgerrit Ed Leafe proposed openstack/nova master: Add Selection objects https://review.openstack.org/499239
16:16:33 openstackgerrit Ed Leafe proposed openstack/nova master: Fix return type in FilterScheduler._legacy_find_hosts https://review.openstack.org/517134
16:16:34 openstackgerrit Ed Leafe proposed openstack/nova master: Modify select_destinations() to return objects and alts https://review.openstack.org/510159
16:16:34 openstackgerrit Ed Leafe proposed openstack/nova master: Return Selection objects from the scheduler driver https://review.openstack.org/495854
16:16:35 openstackgerrit Ed Leafe proposed openstack/nova master: Move the claim_resources method to scheduler utils https://review.openstack.org/511357
16:16:35 openstackgerrit Ed Leafe proposed openstack/nova master: Change RPC for select_destinations() https://review.openstack.org/516707
16:16:36 openstackgerrit Ed Leafe proposed openstack/nova master: Make conductor pass and use host_lists https://review.openstack.org/511358
16:16:53 edleafe mriedem: ^^ your fix got rebased
16:19:11 kashyap mdbooth: I see what you mean; disregard my question. You're talking in context of this new model that Dan was proposing.
16:19:37 mdbooth kashyap: Ah, yes
16:19:54 mriedem ack
16:24:11 kashyap mriedem: Is there an Etherpad for topics to be discussed for those to follow remotely?
16:24:20 kashyap mriedem: I think the place to look at is - http://forumtopics.openstack.org/
16:24:23 kashyap ?
16:25:44 kashyap I'm intersted in this - http://forumtopics.openstack.org/cfp/details/55 (Brainstorming on perf and scale testing for lowly devs)
16:29:29 openstackgerrit Elod Illes proposed openstack/nova master: Transform instance-live_migration_pre notification https://review.openstack.org/482070
16:33:13 openstackgerrit Merged openstack/nova master: libvirt: do not remove inst_base when volume-backed during resize https://review.openstack.org/516395
16:33:20 melwitt mriedem: are you cool with this change now? and will we remove the DNM from the test hook change and the WIP from the tempest change to make sure those get included after? https://review.openstack.org/#/c/507202
16:34:40 mriedem kashyap: https://wiki.openstack.org/wiki/Forum/Sydney2017
16:34:45 mriedem that session on perf was rejected
16:35:05 mriedem kashyap: superseded by http://forumtopics.openstack.org/cfp/details/21
16:35:34 mriedem melwitt: i don't think we're going to turn on volume-backed live migration testing anytime soon, since it was pretty unreliable the last time i tried
16:35:45 kashyap Thanks for the links
16:37:27 melwitt mriedem: oh, bummer, didn't realize it was that unreliable. was thinking they'd be regression tests
16:37:41 mriedem +2 on the bottom change
16:37:54 mriedem melwitt: they might be better, not really sure, would have to run them through a bunch of times to see
16:38:06 mriedem https://bugs.launchpad.net/nova/+bug/1524898
16:38:08 openstack Launchpad bug 1524898 in OpenStack Compute (nova) "Volume based live migration aborted unexpectedly" [High,In progress]
16:38:21 melwitt yep, understood
16:38:26 mriedem now that we're using pike UCA, maybe that's not as bad
16:40:07 melwitt ah, to get newer libvirt and qemu
16:40:20 mriedem yes we now have libvirt 3.6.0 and qemu 2.10
16:42:53 mriedem so we have control over the live migration job per-branch, but the neutron multi-node job runs live migration tests too, and that would maybe start failing on stable branches if we enabled the volume-backed test in tempest; but the neutron multinode job might be non-voting on stable too...
16:43:00 mriedem all things that must be considered...
16:43:49 melwitt good points
16:46:32 openstackgerrit Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215
16:46:32 openstackgerrit Jay Pipes proposed openstack/nova master: placement: add nested resource providers https://review.openstack.org/377138
16:46:33 openstackgerrit Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
16:46:33 openstackgerrit Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
16:46:35 jaypipes efried: ^^ n-r-p rebased.
16:46:44 jaypipes efried: and addressed your comments. thanks.
16:46:52 efried jaypipes Ack.
16:55:24 efried jaypipes https://review.openstack.org/#/c/384807/ -- placement-api-ref update for ?tree= ?
16:55:44 jaypipes efried: good spot. will add.
16:56:12 efried jaypipes Durn patch-level comments always getting lost.
16:56:43 jaypipes efried: currently pulling in the "lost PS3 changes" in https://review.openstack.org/#/c/516778. sorry about that...
16:56:54 efried Cool
16:57:22 melwitt mdbooth: question in this unit test patch, what's the mis-named field? I didn't notice anything in this change or the one above it https://review.openstack.org/#/c/502126/3//COMMIT_MSG
16:59:10 mdbooth melwitt: IIRC the error was in the subsequent test
16:59:27 mdbooth But it wasn't picked up because it was just a mock
17:00:11 melwitt mdbooth: "subsequent test" meaning the test in the next patch right?
17:01:11 mdbooth melwitt: IIRC, yes?
17:01:27 mdbooth I've slept many times since writing that. Almost certainly yes.
17:01:46 mdbooth It doesn't really matter, though, because exactly which test it is doesn't matter.
17:02:06 mdbooth The point is that the way it was written allowed a test to assume the existence of a field which doesn't exist.
17:03:32 melwitt mdbooth: yeah, I get the point, this commit message is so vague there's no way to see or understand what the problem was, is all
17:03:53 mdbooth The problem is it's a Mock, which means anything goes.

Earlier   Later