| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-19 | |||
| 12:46:45 | openstackgerrit | Rico Lin proposed openstack/nova master: Fix Unit test for arm64 https://review.opendev.org/c/openstack/nova/+/768202 | |
| 13:05:02 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [WIP] Add conf option for scatter_gather_cells error handling https://review.opendev.org/c/openstack/nova/+/771440 | |
| 13:11:46 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: `socket` PCI NUMA-affinity Policy https://review.opendev.org/c/openstack/nova-specs/+/765551 | |
| 13:12:32 | artom | sean-k-mooney, stephenfin, gibi ^^ pretty please :) | |
| 13:26:36 | bauzas | stephenfin: question here https://review.opendev.org/c/openstack/nova/+/758394/4/nova/db/sqlalchemy/migrate_repo/versions/231_add_ephemeral_key_uuid.py#b32 with a procedural -1 | |
| 13:59:19 | sean-k-mooney | artom: im going to refill my coffee then ill take a look | |
| 14:02:29 | gibi | artom: refined my question in https://review.opendev.org/c/openstack/nova-specs/+/765551 | |
| 14:22:28 | stephenfin | bauzas: replied | |
| 14:22:36 | bauzas | ta, looking | |
| 14:22:48 | stephenfin | sean-k-mooney: ta is catching on :P ^ | |
| 14:23:18 | sean-k-mooney | hehe i know bauzas and efried started using it | |
| 14:23:34 | bauzas | ta doesn't mean thanks ? | |
| 14:23:38 | sean-k-mooney | eventually ye will all start spelling in sean speak and we will all be doomed | |
| 14:24:09 | stephenfin | bauzas: Yup, it does. sean-k-mooney just made a joke about me using it often some time back | |
| 14:24:09 | sean-k-mooney | bauzas: kind of yes but its an irish/british thing | |
| 14:24:15 | stephenfin | and I said it would catch on :) | |
| 14:24:19 | bauzas | ok, je peux parler en français sinon | |
| 14:24:24 | bauzas | :p | |
| 14:24:39 | bauzas | anyway, saw your reply | |
| 14:24:54 | bauzas | honestly, I'm not a SQLA expert | |
| 14:25:30 | bauzas | so, yeah, the column is *nullable* but I don't know whether the default value is NULL for the SQL | |
| 14:26:20 | bauzas | anyway, maybe it's just a bikeshed | |
| 14:26:22 | sean-k-mooney | gibi: artom seams to have disconencted but i think the spec is wrong | |
| 14:26:40 | sean-k-mooney | if you have hw_numa_nodes=2 N0 and N2 shoudl be fine | |
| 14:26:55 | stephenfin | yeah, gone since 14:10 | |
| 14:27:04 | stephenfin | probably on breakfast/kid duty | |
| 14:27:06 | gibi | sean-k-mooney: that answer I can accept | |
| 14:27:29 | gibi | sean-k-mooney: if at least one CPU is on the same socket as the allocated PCI | |
| 14:27:31 | sean-k-mooney | if you have hw:numa_nodes=2 and the socket policy provide the pci device come form one of the socket of any of the guest numa nodes its fine | |
| 14:27:59 | sean-k-mooney | hw_pci_numa_affinity_policy=socket should not require that all guest numa nodes come from teh same socket | |
| 14:28:17 | sean-k-mooney | gibi: yep | |
| 14:28:44 | gibi | sean-k-mooney: I agre | |
| 14:29:24 | sean-k-mooney | ill comment that on the spec and i guess you can too but i need to read the rest too. i just started with your comment since i saw your ping to artom | |
| 14:30:08 | stephenfin | lyarwood: Yeah, all good on https://review.opendev.org/c/openstack/nova/+/761725 | |
| 14:31:14 | lyarwood | stephenfin: thanks | |
| 14:32:28 | lyarwood | hmm does anyone know where the openstack-dev archive ended up? | |
| 14:33:51 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: `socket` PCI NUMA-affinity Policy https://review.opendev.org/c/openstack/nova-specs/+/765551 | |
| 14:33:56 | spatel | sean-k-mooney: morning! do you have any idea about this Bug? - https://bugs.launchpad.net/nova/+bug/1912273 | |
| 14:33:57 | openstack | Launchpad bug 1912273 in OpenStack Compute (nova) "SRIOV instance Error: Exception during message handling: KeyError: 'pci_slot'" [Undecided,New] | |
| 14:34:08 | bauzas | lyarwood: http://lists.openstack.org/pipermail/openstack-dev/ | |
| 14:34:10 | bauzas | ? | |
| 14:34:32 | lyarwood | bauzas: thanks http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev does't list it anymore | |
| 14:34:48 | bauzas | ack, gtk | |
| 14:37:35 | artom | gibi, thanks for the question, amended the spec :) | |
| 14:37:56 | sean-k-mooney | artom: im replying | |
| 14:38:03 | sean-k-mooney | artom: the spec is incorrect. | |
| 14:40:04 | sean-k-mooney | artom: still review but https://review.opendev.org/c/openstack/nova-specs/+/765551/5/specs/wallaby/approved/pci-socket-policy.rst#82 | |
| 14:41:23 | artom | sean-k-mooney, well, it's kinda up to us to decide what we want - or rather, what we think operators want. | |
| 14:41:41 | sean-k-mooney | sure but i disagree with what you chosse | |
| 14:41:47 | sean-k-mooney | and its inconsitend with require | |
| 14:42:09 | artom | SO, with multiple guest NUMA nodes and a single PCI device, it's obviously impossible to have all guest NUMA nodes pinned to the same host NUMA node containing the PCI device | |
| 14:42:16 | artom | (Well, assuming dedicated CPUs) | |
| 14:42:23 | sean-k-mooney | if we wanted to provide a way to do what you suggested that is a different feature with a different extra spec | |
| 14:42:25 | artom | So for `require` we have no choice | |
| 14:43:00 | artom | For `socket` however, it's perfectly possible to have all the guest NUMA nodes come from the same socket, thus guaranteeing that the guest never has to cross the socket boundary to access the PCI device | |
| 14:43:01 | sean-k-mooney | actully libvirt can do that but you missunderstanding what hw:numa_nodes=2 with require means | |
| 14:44:08 | sean-k-mooney | hw_numa_nodes=2 with hw_pci_numa_affinity_policy=require means the pci device will be on the same numa node as one fo the guest numa nodes | |
| 14:44:34 | sean-k-mooney | each device can be colacate with a different one fo the guests numa nodes | |
| 14:44:39 | artom | sean-k-mooney, I get that, because being on the same host numa node as *both* guest NUMA nodes doens't make sense | |
| 14:44:50 | sean-k-mooney | correct | |
| 14:44:57 | sean-k-mooney | well ig could | |
| 14:44:59 | artom | But being on the same *socket* as both guest NUMA nodes *would* make sense | |
| 14:45:09 | artom | So it's a matter of - what's the most useful? | |
| 14:45:14 | sean-k-mooney | we currenlty dont allow mulitple guest numa nodes to map to one host numa node | |
| 14:45:19 | sean-k-mooney | that is not a guarnette fo the api | |
| 14:45:26 | sean-k-mooney | its an implemantion detail fo the libvirt driver | |
| 14:45:41 | sean-k-mooney | one which strictly speaking operators should not rely on | |
| 14:46:03 | artom | But de facto they do, because nothing except the libvirt driver will ever implement this :P | |
| 14:46:09 | artom | Anways, that's tangential | |
| 14:46:21 | sean-k-mooney | well i have wanted to change that sicne we added numa affinity | |
| 14:46:28 | sean-k-mooney | the intel implematnion did not require this | |
| 14:47:05 | sean-k-mooney | if we want to provide a way for all nuam nodes to be confiend to the same socket | |
| 14:47:14 | sean-k-mooney | i think that is a different feature to pci affintiy | |
| 14:47:39 | artom | Ah, now that does make sense | |
| 14:47:44 | sean-k-mooney | that is more a kin to hw:numa_mem_policy which was never impelmented | |
| 14:48:16 | artom | I guess? But yeah, I see the point - forcing all guest numa nodes to come from the same host socket is a different thing from PCI policy, and you could have both | |
| 14:48:31 | sean-k-mooney | yes | |
| 14:49:13 | sean-k-mooney | so i would personally find it suprising if the pci policy would trigger that behavior | |
| 14:49:28 | sean-k-mooney | espcially coupled with the ablity to set the policy via a neutorn port | |
| 14:52:39 | artom | Fair points, lemme update | |
| 14:56:19 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/train: Use cell targeted context to query BDMs for metadata https://review.opendev.org/c/openstack/nova/+/771407 | |
| 15:02:14 | dcapone2004 | I am having an issue on ussuri where guest centos VMs with SELinux disabled or set to permissive have the systemd process in the VM consume 100% CPU and never goes back down without rebooting the VM | |
| 15:02:18 | dcapone2004 | after rebooting, the issue recurs within several hours | |
| 15:03:46 | dcapone2004 | I have been attempting to google for other reports of this issue and have been unable to find anything and was trying to see if anyone has seen this issue before and knows what might cause it or any type of resolution | |
| 15:05:02 | dcapone2004 | strace on the systemd process in these VMs, just shows a bunch of epoll_pwait like systemd is hung waiting for something | |
| 15:09:00 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: libvirt: Add support for flavor and image defined ephemeral encryption https://review.opendev.org/c/openstack/nova-specs/+/771474 | |
| 15:09:51 | sean-k-mooney | artom: finished with the review | |
| 15:12:01 | artom | sean-k-mooney, cheers! | |
| 15:12:09 | artom | Hrmm, yeah, placement trait would be faster... | |
| 15:12:34 | artom | I just kinda dislike that it's becoming this endless stream of "NEW_FEATURE_TRAIT_TO_HANDLE_ROLLING_UPGRADES" | |
| 15:12:39 | artom | But maybe that's what they're for... | |
| 15:15:11 | sean-k-mooney | well that was basically the entire point of traits | |
| 15:15:20 | sean-k-mooney | so we can expose capabityes and schdule on them | |
| 15:15:42 | sean-k-mooney | although maybe not for you example | |
| 15:15:53 | sean-k-mooney | the feature trait is not actully for rolling upgrdes | |
| 15:16:08 | sean-k-mooney | it can help with that but its for spawn and all move operations | |
| 15:16:19 | sean-k-mooney | so that we would only consider host that support socket affinity | |
| 15:16:30 | sean-k-mooney | which is very useful in a mixed hypervior deployment | |
| 15:28:28 | artom | Note to self, when talking about dicts flying over the wire, do not typo "wire" as "wife" | |
| 15:45:44 | lyarwood | oh my | |