Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-17
15:50:27 mriedem zigo: ^
15:51:19 zigo mriedem: Wonderful, that's very helpful for me, and much better than blacklisting the test.
15:57:28 mriedem easy bp win https://review.openstack.org/#/c/450636/
16:01:34 ArchiFleKs mriedem: thanks a lot i'll follow that
16:05:23 bauzas mriedem: indeed, will look into the vmware log change
16:37:04 cfriesen mriedem: are you planning on updating https://review.openstack.org/#/c/520660/ to query the volume image metadata? (Using _get_bdm_image_metadata() maybe?). If not would you like me to take a crack at it?
16:37:48 mriedem yeah planning on it, was just looking at something related to that
16:42:23 fried_rice Is the multi-node business (e.g. in resource_tracker _init_comput_host) *only* ironic?
16:42:56 fried_rice johnthetubaguy leakypipes mriedem ^
16:44:13 leakypipes fried_rice: no. also vCenter, IIRC.
16:44:17 fried_rice k
16:44:33 leakypipes fried_rice: but Ironic is the canonical example, yes.
16:44:36 dansmith leakypipes: no, it's only ironic
16:44:44 leakypipes dansmith: oh?
16:45:00 dansmith there was a vmware use of it long ago but it's been gone for a while
16:45:05 leakypipes ah, k
16:45:14 leakypipes dansmith: no? :(
16:45:41 dansmith leakypipes: I'm still suffering from Australia Pox
16:45:55 dansmith the country really does try to kill people
16:46:01 leakypipes ouch.
16:48:37 mriedem i think the vcenter multinode thing was removed in kilo
16:50:00 mriedem liberty: https://github.com/openstack/nova/commit/2f7403bd7200a01e350cde9182c273562e0c9c62#diff-9c54c69030bce3e6af0deba002ab6b27
16:51:23 fried_rice Dig, thanks y'all.
16:59:47 leakypipes fried_rice: you on the unit test failure beginning in https://review.openstack.org/#/c/520643/?
17:00:07 fried_rice leakypipes Yes, it's in my sandbox.
17:00:11 leakypipes kk
17:00:14 leakypipes just checkin.
17:00:28 fried_rice leakypipes I'm not hurrying to push it up, since there's so many patches in front of that subseries.
17:00:47 leakypipes k, np. you'd just asked me to review that and the ones above it.
17:00:57 leakypipes in any case, I've added my thoughts.
17:01:00 leakypipes fried_rice: ^
17:01:26 fried_rice leakypipes Yeah, the ones not marked WIP should be ready, and (assuming no review-prompted changes) should only need rebases once that UT fix goes in.
17:09:00 mriedem cfriesen: oh another thing, today we *always* update instance.image_ref to the new image id provided during rebuild, so even if you rebuild a bfv instance with the same image as the original, we break that contractual thing in the API where instance.image_ref == None means volume-backed
17:14:27 tbachman fried_rolls: menu change?
17:14:51 cfriesen yeah...was thinking that we'd have to modify your patch to make that update conditional on BFV, and potentially deal with fallout from code expecting instance.image_ref to be set
17:15:08 cfriesen mriedem: ^
17:17:27 mriedem code as in rebuild code in the compute service?
17:20:13 openstackgerrit Andrey Kurilin proposed openstack/python-novaclient master: [ci] Use pseudo-random names for new resources https://review.openstack.org/479777
17:20:13 openstackgerrit Andrey Kurilin proposed openstack/python-novaclient master: [functional] Remove duplication of boot helper https://review.openstack.org/521071
17:21:07 cfriesen mriedem: yes
17:22:07 mriedem problem with that is, we could have backlevel computes, assuming there would need to be a change in the computes to handle that
17:22:13 cfriesen mriedem: alternately we'd have to switch to some other method of representing BFV, or else have nova-api null it out for BFV instances
17:22:23 mriedem but it shouldn't be a problem b/c i think we pass the new image_id down through rpc
17:24:09 cfriesen mriedem: just realized that _get_bdm_image_metadata() will give the image metadata, but not the image id itself.
17:26:09 mriedem yeah it should because of compute.utils.get_image_metadata_from_volume
17:26:30 mriedem oh nvm you're right
17:26:32 mriedem i think
17:26:43 cfriesen that loops over VIM_IMAGE_ATTRIBUTES and pops them
17:30:52 cfriesen mriedem: I think we want something like this...totally untested and partly copied from_get_bdm_image_metadata() : http://paste.openstack.org/show/626644/
17:33:22 cfriesen could even move it down a bit after we calculate root_bdm and save doing it twice.
17:41:41 cfriesen mriedem: new version, cleaned up a bit: http://paste.openstack.org/show/626648/
17:42:19 mriedem you shouldn't need "if snapshot_id:"
17:42:30 mriedem a bdm that is attached to an instance should always have volume_id set
17:42:42 mriedem if you bfv with a snapshot, nova creates a volume from the snapshot and stores the created volume_id on the bdm
17:43:10 cfriesen ah, okay
17:43:21 mriedem feel free to update my change with a co-author
17:43:25 mriedem i'm in the middle of something else
17:43:36 cfriesen sure
17:43:58 cfriesen should solve the other bug as well I think, by not going through the scheduler if they're the same
17:48:49 openstackgerrit Chris Friesen proposed openstack/nova master: WIP: Fail fast if changing image on a volume-backed server rebuild https://review.openstack.org/520660
17:50:49 cfriesen crud, messed that up
17:52:46 openstackgerrit Chris Friesen proposed openstack/nova master: WIP: Fail fast if changing image on a volume-backed server rebuild https://review.openstack.org/520660
17:54:43 alaski \quit
17:54:46 alaski \quit
17:54:54 alaski grr
17:54:59 dansmith cover. blown.
18:10:33 leakypipes mriedem: bottom five patches in validate_provider_summaries series are signed off by alex now, starting here: https://review.openstack.org/#/c/516778
18:19:41 mriedem dansmith: ^
18:19:41 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add regression test for rebuild with new image doubling allocations https://review.openstack.org/521153
18:20:01 mriedem gonna work on the todo in there to not use placement for getting the usage
18:20:28 dansmith mriedem: you wanna I work on the actual fix then?
18:20:42 mriedem if you have a pretty clear idea on how to start it, sure
18:20:59 dansmith I don't have pretty clear anything these days, but I'll get it rolling
18:21:12 dansmith mriedem: you specifically don't want to revert and re-fix then?
18:21:23 mriedem idk
18:21:36 dansmith for my backports it'd be much cleaner if we reverted,
18:21:36 mriedem also, bypassing filters is one thing, but we'd also have to apply that to bypassing placement
18:21:51 dansmith but I understand the optics of reverting a cve
18:36:31 dansmith mriedem: imagepropertiesfilter is what will kick out your test instance right?
18:36:49 mriedem test_rebuild_with_image_novalidhost
18:36:49 mriedem in which test?
18:37:11 dansmith your new one
18:37:18 dansmith test_rebuild_with_new_image
18:37:23 mriedem in the new test, the scheduler doesn't kick it out
18:37:32 mriedem it asserts that it's incorrectly doubling allocations
18:37:40 dansmith but you're changing a thing that properties filter would kick out/
18:37:48 mriedem if i maxed out inventory on the node before the rebuild, then placement would kick it out
18:38:08 mriedem ?
18:38:20 mriedem that's the test that went with the cve
18:38:43 dansmith right, what am I thinking.
18:39:04 mriedem are you expecting the new test to create, fill up compute capacity, then rebuild and fail?
18:39:14 dansmith no
18:39:31 mriedem ok - we probably want a test like that anyway, what i'm testing in the new one is something else, and equally bad
18:39:32 dansmith I still have mitaka on the brain, I was forgetting that master is already "fixed"
18:44:57 dansmith mriedem: so your test_rebuild_with_image_novalidhost passes if I remove your requested_destination= change
18:45:41 dansmith does that test actually have more than one compute in it?
18:45:54 mriedem no it doesn't
18:46:27 mriedem it passes because the rebuild fails yes?
18:47:04 dansmith well, I dunno, I'll have to look deeper
18:47:53 dansmith it fails if I also remove the host=None trigger

Earlier   Later