Earlier  
Posted Nick Remark
#openstack-nova - 2017-11-02
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: Fix return type in FilterScheduler._legacy_find_hosts https://review.openstack.org/517134
16:16:33 openstackgerrit Ed Leafe proposed openstack/nova master: Add Selection objects https://review.openstack.org/499239
16:16:34 openstackgerrit Ed Leafe proposed openstack/nova master: Return Selection objects from the scheduler driver https://review.openstack.org/495854
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:35 openstackgerrit Ed Leafe proposed openstack/nova master: Change RPC for select_destinations() https://review.openstack.org/516707
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: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: add nested resource providers https://review.openstack.org/377138
16:46:32 openstackgerrit Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215
16:46:33 openstackgerrit Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
16:46:33 openstackgerrit Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
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.
17:04:09 mdbooth It could have been anything. Exactly what it was doesn't really matter.
17:04:11 openstackgerrit Jay Pipes proposed openstack/nova master: begin refactor AllocCandidates._get_by_filters() https://review.openstack.org/516778
17:04:12 openstackgerrit Jay Pipes proposed openstack/nova master: build ProviderSummary objects in sep function https://review.openstack.org/516779
17:04:12 openstackgerrit Jay Pipes proposed openstack/nova master: build alloc request resources for shared resources https://review.openstack.org/516780
17:04:13 openstackgerrit Jay Pipes proposed openstack/nova master: create allocation request for single provider https://review.openstack.org/516781
17:04:13 openstackgerrit Jay Pipes proposed openstack/nova master: finish refactor AllocCandidates._get_by_filters() https://review.openstack.org/516782
17:04:14 openstackgerrit Jay Pipes proposed openstack/nova master: required traits for no sharing providers https://review.openstack.org/517027
17:04:14 openstackgerrit Jay Pipes proposed openstack/nova master: WIP: handle traits with sharing providers https://review.openstack.org/517119
17:04:17 jaypipes efried: k, done ^
17:04:31 efried woot
17:04:32 melwitt mdbooth: yes, I get that. I wanted to see where a "mis-named field" was occuring for my own edification

Earlier   Later