| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-12 | |||
| 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 | efried | mriedem: ack | |
| 15:27:48 | mriedem | linked to CI results that use that image handler | |
| 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 | aha self.useFixture(fixtures.MonkeyPatch( | |
| 15:38:40 | mriedem | 'nova.virt.libvirt.driver.libvirt_utils', | |
| 15:38:40 | mriedem | fake_libvirt_utils)) | |
| 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_LIBVIRT_FILE_BACKED_VERSION = (4, 0, 0) | |
| 15:48:03 | mriedem | MIN_QEMU_FILE_BACKED_VERSION = (2, 6, 0) | |
| 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:10 | mriedem | ii qemu-system-x86 1:2.11+dfsg-1ubuntu7~cloud0 | |
| 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 | |
| 15:55:04 | dansmith | mriedem: in case it's not clear, because the sending host's libvirt gets to choose the xml for the destination, if it's old and doesn't know about this, | |
| 15:55:12 | zcorneli | dansmith: Ah. Wasn't catching that. | |
| 15:55:14 | dansmith | it will generate xml that violates the config of the remote side | |