| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-12 | |||
| 15:00:20 | mriedem | we could have a gap here | |
| 15:00:54 | mriedem | maybe all that's needed is a release note saying don't set enable_certificate_validation=True in your computes until the API is upgraded to rocky | |
| 15:02:10 | bpoulos | yeah, I can add that release note. It also wouldn't hurt to check for the default ids at that point, since there wouldn't be a risk of overriding the user-provided certs | |
| 15:02:59 | mriedem | we don't need a reno if the download() code condition where trusted_certs is None and enable_certificate_validation=True uses the default certs | |
| 15:03:39 | bpoulos | ok, I'll just make the change then (along with addressing the other comments) | |
| 15:03:55 | mriedem | ok thanks | |
| 15:03:59 | bpoulos | thank you for your feedback! I appreciate you taking a detailed look at the implementation | |
| 15:04:31 | mriedem | np, i want to go through this series in detail again today, and i'll probably address any minor issues myself if i come across them to keep things going, just fyi | |
| 15:05:12 | bpoulos | ok, great, thanks for the heads up | |
| 15:07:33 | edleafe | Question for all you boot-from-volume experts. Can a running VM that is booted from a volume resize that volume? Or must it be taken offline first? | |
| 15:09:41 | openstackgerrit | Merged openstack/nova master: Do not use nova.test in placement.handlers.test_aggregate https://review.openstack.org/574404 | |
| 15:09:47 | openstackgerrit | Merged openstack/nova master: Do not use nova.test in placement.test_requestlog https://review.openstack.org/574405 | |
| 15:09:54 | openstackgerrit | Merged openstack/nova master: Do not use nova.test in placement.test_fault_wrap https://review.openstack.org/574406 | |
| 15:10:01 | openstackgerrit | Merged openstack/nova master: Do not use nova.test in placement.test_handler https://review.openstack.org/574407 | |
| 15:11:19 | lyarwood | edleafe: that depends on the volume and virt drivers being used | |
| 15:11:21 | lyarwood | edleafe: https://developer.openstack.org/api-ref/block-storage/v3/index.html#extend-a-volume-size | |
| 15:12:06 | jmccarthy | Anyone have a min to look at this request req-2d031a52-360a-4425-bdf9-1d7630833b43 in nova-api.log | |
| 15:12:07 | jmccarthy | https://paste.fedoraproject.org/paste/mUjA9N7upfW0gqmeXjgRMw ? | |
| 15:12:07 | jmccarthy | It's a deadlock timeout that seems to be happening fairly often (kolla queens, mysqlcluster database) | |
| 15:12:57 | jmccarthy | Sorry for copy and paste of same question - or if folks have any general suggestions if deadlocks are occuring with nova calls | |
| 15:13:29 | openstackgerrit | Alexandre arents proposed openstack/nova master: Preserve images_type of instance during live migration https://review.openstack.org/570528 | |
| 15:13:33 | jmccarthy | The deletion of instances seems like an area where it happens more often | |
| 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 | 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 | |