| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-05-11 | |||
| 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 | |
| 14:25:24 | sean-k-mooney | lyarwood: ^ any toughts on the topic | |
| 14:26:07 | sean-k-mooney | we are just adding a namespaced version of an existing unnamsepaced extra_spec | |
| 14:26:29 | sean-k-mooney | downstream that is not conisderd an api change since extra_specs are not part of the api | |
| 14:26:35 | lyarwood | sean-k-mooney: reading | |
| 14:27:34 | openstackgerrit | James Page proposed openstack/nova stable/queens: hardware: fix memory check usage for small/large pages https://review.opendev.org/726867 | |
| 14:28:58 | sean-k-mooney | lyarwood: actully that is not the patch i ment to link | |
| 14:29:34 | lyarwood | sean-k-mooney: right you had me slightly confused tbh | |
| 14:29:50 | sean-k-mooney | that one we might also want to backport but one sec | |
| 14:29:58 | lyarwood | yeah that's looks valid to backport | |
| 14:30:01 | lyarwood | that* | |
| 14:30:04 | sean-k-mooney | https://review.opendev.org/#/c/722187/ | |
| 14:30:08 | sean-k-mooney | that is the one i ment | |
| 14:30:27 | sean-k-mooney | for https://bugs.launchpad.net/nova/+bug/1841932 | |
| 14:30:27 | openstack | Launchpad bug 1841932 in OpenStack Compute (nova) "hide_hypervisor_id extra_specs in nova flavor cannot pass AggregateInstanceExtraSpecsFilter" [Low,In progress] - Assigned to Stephen Finucane (stephenfinucane) | |
| 14:33:03 | lyarwood | sean-k-mooney: so we deprecate hide_hypervisor_id in that change but still provide backward compatability so at first glance I think we can backport this upstream? | |
| 14:33:36 | sean-k-mooney | lyarwood: correct deprecated but still supported | |
| 14:33:49 | sean-k-mooney | we would have to drop the validation changes | |