| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-19 | |||
| 10:26:58 | stephenfin | yeah, I don't think there'll be a case where patch N has to change because of something in M, if that's what you mean. No dependencies | |
| 10:27:10 | stephenfin | at least not in that way | |
| 10:36:27 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Liberty database migrations https://review.opendev.org/c/openstack/nova/+/759399 | |
| 10:36:31 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Newton database migrations https://review.opendev.org/c/openstack/nova/+/759401 | |
| 10:36:31 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Mitaka database migrations https://review.opendev.org/c/openstack/nova/+/759400 | |
| 10:36:32 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Pike database migrations https://review.opendev.org/c/openstack/nova/+/759403 | |
| 10:36:32 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Ocata database migrations https://review.opendev.org/c/openstack/nova/+/759402 | |
| 10:36:33 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Rocky database migrations https://review.opendev.org/c/openstack/nova/+/759405 | |
| 10:36:33 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Queens database migrations https://review.opendev.org/c/openstack/nova/+/759404 | |
| 10:36:34 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Add manage.py script https://review.opendev.org/c/openstack/nova/+/771419 | |
| 10:36:34 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Stein database migrations https://review.opendev.org/c/openstack/nova/+/759406 | |
| 10:36:35 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Train database migrations https://review.opendev.org/c/openstack/nova/+/771420 | |
| 10:43:22 | bauzas | stephenfin: no worries, for the moment, I don't see any issue with this | |
| 11:04:51 | elod | lyarwood: I've commented on the train backport patch you mentioned yesterday | |
| 11:06:35 | elod | lyarwood: this one: https://review.opendev.org/c/openstack/nova/+/770944 | |
| 11:07:01 | elod | lyarwood: I'd rather not backport those 2 patches :/ | |
| 11:09:08 | lyarwood | elod: ack, I'll add context in the review but tl;dr downstream our OSP 16 release maps to stable/train and we plan on keeping it around until ~2025 https://access.redhat.com/support/policy/updates/openstack/platform/ | |
| 11:09:26 | lyarwood | elod: we've backported a few things downstream and hit issues with pyflakes 1.2.3 not supporting f-strings | |
| 11:09:41 | lyarwood | elod: and assume that in the future we could easily also land things upstream that hit the same issue | |
| 11:10:04 | lyarwood | elod: as this is just a lint tooling bump we thought we'd try to land this in stable/train first before doing anything downstream only | |
| 11:10:29 | lyarwood | maybe that wasn't a true tl;dr but hopefully you see what I was trying to do now ;) | |
| 11:15:42 | elod | lyarwood: in train python 2 is still there, and f-sting is not in python2 | |
| 11:16:20 | elod | I guess you support train with python3 (of course) | |
| 11:16:55 | lyarwood | elod: yeah indeed only on py36 downstream | |
| 11:17:12 | lyarwood | elod: was it a supported runtime in stable/train? | |
| 11:17:29 | lyarwood | ah it was | |
| 11:17:33 | lyarwood | okay then ignore me | |
| 11:17:35 | elod | the job is still there | |
| 11:17:37 | lyarwood | sorry I thought it wasn't | |
| 11:17:39 | lyarwood | https://governance.openstack.org/tc/reference/runtimes/train.html | |
| 11:17:45 | lyarwood | I'll just backport these downstream | |
| 11:17:53 | lyarwood | apologies for the noise | |
| 11:18:38 | elod | lyarwood: ussuri is the 1st one without py2 | |
| 11:18:46 | elod | lyarwood: no problem | |
| 11:19:15 | lyarwood | yup ETOOMANYVERSIONS :) | |
| 11:19:22 | elod | lyarwood: I just don't feel it appropriate upstream :/ | |
| 11:19:45 | lyarwood | yup it isn't if we support py27 still as f-strings are not valid in stable/train as a result | |
| 11:19:58 | lyarwood | I'll just modify the backports downstream to avoid this and move on | |
| 11:20:07 | lyarwood | as it's only f-strings | |
| 11:20:31 | elod | lyarwood: ok, thanks | |
| 11:24:05 | bauzas | stephenfin: man, I don't know how other people do for reviewing your DB changes, but it'll need time for me for looking at all the modifications for https://review.opendev.org/c/openstack/nova/+/758394/4 | |
| 11:25:37 | stephenfin | bauzas: You can put this script in the root of your nova repo, run it on master and then it run after the change is applied, comparing the diff (there shouldn't be one) https://review.opendev.org/c/openstack/nova/+/769796 | |
| 11:25:46 | stephenfin | I've done that a few times now | |
| 11:49:41 | openstackgerrit | Merged openstack/nova stable/ussuri: Use cell targeted context to query BDMs for metadata https://review.opendev.org/c/openstack/nova/+/765748 | |
| 12:46:40 | openstackgerrit | Rico Lin proposed openstack/nova master: add openstack-python3-wallaby-jobs-arm64 job https://review.opendev.org/c/openstack/nova/+/742094 | |
| 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 | |