Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-12
15:13:36 edleafe lyarwood: thanks. Does it matter if the volume is running as the boot volume? That's the part I couldn't find.
15:15:55 cfriesen is anyone aware of an issue where an RBD-backed swap disk is not restored to the initial size after a resize/revert? We're hitting this on Pike.
15:16:46 cfriesen also, we're seeing a second issue where the guest has to manually re-run "mkswap" after a resize/confirm otherwise it still keeps using the old size of swap
15:17:57 lyarwood edleafe: good question, https://review.openstack.org/#/c/454322/ is the Nova change and AFAICT it does support extending the boot volume
15:22:12 edleafe lyarwood: yeah, looks like we'll need to test this first
15:23:48 mriedem edleafe: https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/nova-support-attached-volume-extend.html#other-end-user-impact
15:24:01 mriedem as far as i know, there are no restrictions in openstack on the root volume
15:24:09 mriedem but either way, the guest has to resize
15:24:46 mriedem garyk: done
15:24:57 dansmith mriedem: you mean the guest has to resize the filesystem
15:25:05 mriedem garyk: but to be clear, i won't +2 that change until the vmware ci is passing with a live migration run
15:25:10 mriedem dansmith: yes
15:25:16 mriedem "The end user will have to perform a partition and/or filesystem resize to fully benefit from the new volume size."
15:25:52 dansmith yup, okay just making sure, because edleafe's original question almost sounded like the guest was triggering the resize of the volume, which isn't a thing
15:26:06 garyk mriedem: thanks!
15:26:08 dansmith "Can a VM...resize that volume"
15:27:40 mriedem efried: +2 on the vdi_remote_stream xenapi change now https://review.openstack.org/#/c/486475/
15:27:48 mriedem linked to CI results that use that image handler
15:27:48 efried mriedem: ack
15:28:47 efried mriedem: +A
15:28:52 mriedem sweet
15:29:14 mriedem melwitt: we can drop the xenapi image handler bp from the runways slot, the changes are all approved https://review.openstack.org/#/q/topic:bp/xenapi-image-handler-option-improvement+(status:open+OR+status:merged)
15:29:38 edleafe dansmith: yeah, bad wording
15:30:04 edleafe dansmith: the resize would be from an admin API call.
15:30:49 dansmith edleafe: cool, just nitting on the words :)
15:31:38 mriedem efried: so it looks like the 'report cpu features as traits' change finally got life again https://review.openstack.org/#/c/560317/
15:31:42 mriedem just in time for a runway slot
15:31:47 mriedem albeit functional tests failing
15:31:53 efried k
15:32:03 mriedem alex_xu: if you're around, do you think 'report cpu features as traits' https://review.openstack.org/#/c/560317/ is ready for a runway slot?
15:33:36 mriedem it's failing dansmith's favorite tests
15:33:39 mriedem http://logs.openstack.org/17/560317/7/check/nova-tox-functional/3d9f8d1/testr_results.html.gz
15:34:36 mriedem AttributeError: 'module' object has no attribute 'CPU_TRAITS_MAPPING'
15:38:33 mriedem test_create_server_with_pinning
15:38:35 mriedem oops
15:38:40 mriedem fake_libvirt_utils))
15:38:40 mriedem 'nova.virt.libvirt.driver.libvirt_utils',
15:38:40 mriedem aha self.useFixture(fixtures.MonkeyPatch(
15:40:19 mriedem efried: didn't add your requested functional test though...
15:40:52 efried mriedem: We're still talking about cpu traits?
15:41:11 openstackgerrit Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766
15:41:12 openstackgerrit Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435
15:41:13 openstackgerrit Chris Dent proposed openstack/nova master: Ensure that os-traits sync is attempted only at start of process https://review.openstack.org/553857
15:41:14 efried mriedem: I'm not going to get to it for a little bit here. If there's anything I need to know, please note it in the review?
15:41:46 mriedem no, i'm just looking for the next runway slot taker, which would have been this, but they didn't address your last -1 from may 29
15:41:55 mriedem so, probably not really ready for a slot
15:42:44 mriedem zcorneli: is your libvirt file-backed memory changes ready for review in the runway slot and you'll be around for the next 2 weeks to answer questions and rev the changes?
15:43:05 dansmith mriedem: the first refactor is ripe for +W by efried I think
15:43:18 zcorneli mriedem: Yep, ready for review, and next 2 weeks are good for me.
15:43:24 efried dansmith: link?
15:43:40 dansmith efried: I think you were waiting for zuul on this since you were +2 before? https://review.openstack.org/#/c/571030/4
15:44:00 mriedem i expected to see some conductor changes in https://review.openstack.org/#/c/567876/ but i guess i need to read the spec
15:44:19 efried dansmith: +A, thanks for the heads up.
15:44:20 mriedem and/or scheduler request filter, something like that
15:44:56 dansmith mriedem: I think what you're looking for is in the pre source/dest calls
15:45:53 mriedem hmmm yeah, ok
15:45:58 mriedem will throw it into the open slot
15:46:01 mriedem and rip it up later :)
15:46:14 dansmith I'm a little wary of approving that without a test though
15:46:20 dansmith a real one I mean
15:46:36 edleafe lyarwood: ugh, they're running Mitaka
15:46:54 mriedem edleafe: s/they're/everyone's/
15:47:46 edleafe mriedem: I'd laugh if that weren't true
15:47:51 mriedem dansmith: good news is,
15:48:03 mriedem MIN_QEMU_FILE_BACKED_VERSION = (2, 6, 0)
15:48:03 mriedem MIN_LIBVIRT_FILE_BACKED_VERSION = (4, 0, 0)
15:48:10 mriedem ii qemu-system-x86 1:2.11+dfsg-1ubuntu7~cloud0
15:48:10 zcorneli dansmith: Yea, I think I need to make a real test for the migration checks. Guess I need to figure out how to set that up.
15:48:17 mriedem ii libvirt-bin 4.0.0-1ubuntu7~cloud0
15:48:23 mriedem we can totally test this in the gate
15:48:30 mriedem zcorneli: i can help you there
15:48:36 dansmith mriedem: well, we'll need to fake some file-backed memory
15:48:51 zcorneli mriedem: Woo! Help is always good.
15:49:11 mriedem oh right...
15:49:19 dansmith mriedem: it's doable
15:49:21 mriedem if we don't have file-backed memory on these hosts then
15:49:45 dansmith mriedem: mount tmpfs on /var/lib/qemu/whatever and configure it on
15:49:51 zcorneli dansmith: mriedem: perhaps a tmpfs? Not sure if that's configurable as part of gate tests, but it wouldn't need to be very big
15:49:57 dansmith zcorneli: yep :)
15:50:59 mriedem i'm thinking we'd need a devstack flag
15:51:13 mriedem ENABLE_FILE_BACKED_MEMORY
15:51:20 dansmith mriedem: just to be clear, the thing I think we need to test is old/new computes across this boundary
15:51:28 dansmith mriedem: is that what you were thinking?
15:51:29 mriedem we could do that with the grenade live migration job
15:51:39 mriedem which runs live migration back and forth
15:51:54 dansmith because in that case, a one-off DNM patch to prove it does it right now would address my concern I think
15:51:59 mriedem http://logs.openstack.org/76/567876/10/check/legacy-grenade-dsvm-neutron-multinode-live-migration/df96c54/
15:52:05 dansmith oh
15:52:07 dansmith sweet
15:52:15 mriedem that's queens<>rocky live migration both ways
15:52:35 dansmith yeah, but still, you're not going to always configure file-backed memory for that job, just a one-off yeah?
15:52:44 mriedem we could do it in a one off
15:52:48 mriedem or an experimental queue job
15:52:50 mriedem that's run on demand
15:52:54 dansmith aye
15:53:08 mriedem if someone wants to work on the devstack changes for that we could link it up
15:53:45 dansmith okay
15:54:04 zcorneli Would we be able to validate that old -> new+file_backed fails?
15:54:09 zcorneli ( / is rejected )
15:54:29 dansmith zcorneli: well, that's why it needs to be a one-off or something special I think

Earlier   Later