| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-05-11 | |||
| 09:38:33 | bauzas | good morning Nova | |
| 10:33:42 | stephenfin | lyarwood, bauzas: would you do me the honours? https://review.opendev.org/#/c/710238/ | |
| 10:34:12 | stephenfin | hahaha | |
| 10:34:18 | bauzas | "would you do me the homous" ? | |
| 10:36:45 | gibi | I got an interesting support case downstream. Does nova calculate the disk usage of its own image cache on the compute? | |
| 10:37:20 | stephenfin | gibi: I don't think nova includes anything except instances in those calculation | |
| 10:37:21 | stephenfin | *s | |
| 10:37:33 | gibi | all the non-nova disk usage should be configured in reserved_host_disk_mb | |
| 10:37:44 | stephenfin | I'd expect image cache to be included in the reserved host config | |
| 10:37:48 | stephenfin | yeah | |
| 10:38:00 | gibi | for that I would need to know the maximum size of the image cache | |
| 10:38:02 | bauzas | stephenfin: I'm not a multi-attach specialist | |
| 10:38:16 | bauzas | but I wonder why we were avoiding QEMU>2.10 | |
| 10:38:26 | gibi | do we have a way to maximize the size of the nova image cache? | |
| 10:38:38 | gibi | I mean limit | |
| 10:38:52 | stephenfin | bauzas: I think kashyap explained that to me at some point. Let me look | |
| 10:38:57 | stephenfin | it's a weird conditional, for sure | |
| 10:39:11 | stephenfin | gibi: I'm not aware of any, but I suspect there must be something. /me looks | |
| 10:39:48 | gibi | I tried to find it but I failed | |
| 10:39:57 | bauzas | stephenfin: yeah I suspect something was borked | |
| 10:40:12 | bauzas | but this whole comment is confusing | |
| 10:40:20 | bauzas | it's an "or" clause | |
| 10:40:36 | bauzas | so in theory, we should only support multiattach if QEMU<2.10 | |
| 10:40:51 | bauzas | but I suspect the wording being incorrect, hence the confusion | |
| 10:42:39 | stephenfin | gibi: Yeah, I can't see anything either. Sounds like a gap :-\ | |
| 10:45:10 | stephenfin | bauzas: okay, the context in in https://bugzilla.redhat.com/show_bug.cgi?id=1378242 | |
| 10:45:10 | openstack | bugzilla.redhat.com bug 1378242 in libvirt "QEMU image file locking (libvirt)" [Unspecified,Closed: errata] - Assigned to pkrempa | |
| 10:45:52 | gibi | stephenfin: thanks for confirming. I will do a problem reproduction and file a bug but I feel this will be considered as a feautre request | |
| 10:45:56 | stephenfin | tl;dr: QEMU added a feature that broke multi-attach, which necessitated a new libvirt feature to fix it again | |
| 10:45:58 | gibi | from upstream perspective | |
| 10:46:33 | bauzas | stephenfin: cool, and the bug is readable without being internal | |
| 10:47:34 | bauzas | stephenfin: okay, so the libvirt version is superseding the QEMU one | |
| 10:47:40 | stephenfin | gibi: Perhaps. A quick look suggests we have documented multiple error codes for the API though, so if it was classified as a bug, it should be a backportable one | |
| 10:48:04 | gibi | stephenfin: which API you are referring to? | |
| 10:48:14 | bauzas | stephenfin: worth respinning a better commit msg explaining this ? | |
| 10:48:21 | stephenfin | bauzas: Yup. You either need to use an older version of QEMU, or you need a newer version of libvirt to workaround the changes in newer QEMU | |
| 10:48:34 | stephenfin | bauzas: Good call. Let me do that | |
| 10:48:45 | bauzas | and the fact we have a recent QEMU isn't a problem since libvirt fixes this | |
| 10:49:00 | bauzas | stephenfin: thanks | |
| 10:49:16 | stephenfin | gibi: The host aggregate image caching API. Commit 339129870692467b703220dbc3905fd8bffe6a83 | |
| 10:50:59 | gibi | stephenfin: ohh. This goes way beyond that. As nova cached images before that API was added. | |
| 10:51:37 | gibi | based on images download for new instance boots | |
| 10:51:43 | stephenfin | Ah, the old just-in-time caching behavior? | |
| 10:51:47 | gibi | jepp | |
| 10:51:55 | gibi | as far as I see that is also not limited in size | |
| 10:52:21 | lyarwood | gibi: is this with the libvirt virt driver? | |
| 10:52:27 | gibi | lyarwood: yes libvirt | |
| 10:52:37 | gibi | lyarwood: the instances dir is on local file system | |
| 10:52:47 | lyarwood | gibi: right then you're correct that isn't limited AFAIK | |
| 10:53:43 | gibi | isn't it even a security concern? Can I will the disk via the cache to prevent nova-compute for booting VMs? | |
| 10:53:56 | gibi | s/will/fill/ | |
| 10:54:19 | lyarwood | gibi: that should be taken into consideration when attempting to schedule instances to the node | |
| 10:54:31 | lyarwood | gibi: the cache is just a way of sharing the base image between instances | |
| 10:54:32 | gibi | lyarwood: but it doesn't as far as I see | |
| 10:55:19 | lyarwood | gibi: are you providing a unique image with every request? | |
| 10:56:11 | gibi | lyarwood: if I have a raw base image and two qcow2 guest image then I potentially use original image.size + instance 1 flavor.disk + instance 2 flavor.disk, but nova only calculate the instance 1 flavor.disk + instance 2 flavor.disk as used | |
| 10:57:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Remove MIN_LIBVIRT_MULTIATTACH https://review.opendev.org/710238 | |
| 10:57:28 | stephenfin | bauzas: ^ | |
| 10:57:29 | gibi | (I ignore disk_available_least as placement does not use that just he old removed DiskFilter used that) | |
| 10:58:07 | lyarwood | gibi: don't we report the adjusted available space to placement taking that into account? | |
| 10:58:15 | lyarwood | gibi: the size of the RAW base file that is | |
| 10:58:27 | lyarwood | gibi: and the potential size of the two qcow2 instance disks? | |
| 10:59:42 | lyarwood | _get_disk_over_committed_size_total ? | |
| 11:00:15 | lyarwood | ah right | |
| 11:00:21 | lyarwood | we don't actually report that back up sorry | |
| 11:00:27 | gibi | http://paste.openstack.org/show/793375/ I don't see adjustements in placement based on this | |
| 11:01:36 | lyarwood | ewww | |
| 11:02:21 | gibi | lyarwood: for me either the size of the cache should be configurable (and then we can account for that in reserved_host_disk_mb) or nova needs to report cached disk usage as used in placement | |
| 11:02:52 | lyarwood | gibi: yeah I'd say the latter, I honestly thought we did already. | |
| 11:04:25 | gibi | lyarwood: this is a bug in pike for one of our customers so I also have to think about a backportable solution | |
| 11:04:58 | gibi | lyarwood: do you think that determining the size of the image cache is easy? | |
| 11:05:18 | gibi | is it just some file system calls in the _base dir, isn't it? | |
| 11:05:48 | lyarwood | gibi: yes for file based backends | |
| 11:06:27 | gibi | I have close to zero knowledge on non file based backends behavior | |
| 11:07:13 | lyarwood | gibi: we don't cache in rbd iirc | |
| 11:07:33 | gibi | is there a way to turn of the cache? | |
| 11:07:53 | gibi | for file based backend? (that would be a workaround in my downstream issue) | |
| 11:09:48 | lyarwood | gibi: I don't think so, you can disable the manager but I think we still cache things at creation time | |
| 11:10:00 | lyarwood | gibi: the manager just doesn't run to clean things up | |
| 11:10:20 | gibi | lyarwood: thanks | |
| 11:57:19 | openstackgerrit | Sasha Andonov proposed openstack/nova master: rbd_utils: increase _destroy_volume timeout https://review.opendev.org/705764 | |
| 12:07:09 | nightmare_unreal | how can I determine default api version used by osc CLI ? suppose if we don't specify --os-compute-api-version , which version will it take and how it's determined ? | |
| 12:10:14 | lyarwood | nightmare_unreal: https://docs.openstack.org/api-guide/compute/microversions.html#version-discovery - I think there's also an osc command for that | |
| 12:10:36 | nightmare_unreal | Thanks :) | |
| 12:52:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Note the ``hw_numa_nodes`` image property https://review.opendev.org/683849 | |
| 13:34:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: SR-IOV passthrough: Check PF only if VF is enabled https://review.opendev.org/476642 | |
| 13:36:19 | jsuchome | dansmith: Hi, I've updated related patchets about that direct rbd download (including the spec) could you give it another look? | |
| 13:46:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Poison netifaces.interfaces() in tests https://review.opendev.org/671773 | |
| 13:46:51 | dansmith | jsuchome: yep will queue for today | |
| 13:51:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Raise if flavor and image disagree on hide_hypervisor_id https://review.opendev.org/663365 | |
| 14:17:16 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Revert "nova shared storage: rbd is always shared storage" https://review.opendev.org/726861 | |
| 14:17:35 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/stein: Revert "nova shared storage: rbd is always shared storage" https://review.opendev.org/726862 | |
| 14:17:50 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/rocky: Revert "nova shared storage: rbd is always shared storage" https://review.opendev.org/726863 | |
| 14:18:03 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: Revert "nova shared storage: rbd is always shared storage" https://review.opendev.org/726864 | |
| 14:23:41 | sean-k-mooney | by the way are we planning to backport https://review.opendev.org/#/c/663365/ upstream | |
| 14:24:02 | sean-k-mooney | its the fix for bug@ #1831723 | |
| 14:24:18 | sean-k-mooney | bug: #1831723 | |
| 14:24:18 | openstack | bug 1831723 in OpenStack Compute (nova) "The flavor hide_hypervisor_id value can be overridden by the image img_hide_hypervisor_id" [Undecided,In progress] https://launchpad.net/bugs/1831723 - Assigned to Stephen Finucane (stephenfinucane) | |
| 14:24:50 | sean-k-mooney | downstream i think we would want to backport that as im sure customer will hit it at some point | |
| 14:25:10 | sean-k-mooney | but it might be nice to backport upstream too but im not sure its allowed | |