| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-07-24 | |||
| 08:12:09 | bauzas | but GRID 16 and 17 transition around RHEL9 | |
| 08:12:25 | bauzas | both support some RHEL9 versions, just not the same | |
| 08:12:36 | bauzas | GRID16 is also a LTE version | |
| 08:12:53 | bauzas | while GRID17 is only a production version, ie. with a 1-year term support | |
| 08:14:05 | bauzas | https://docs.nvidia.com/vgpu/16.0/product-support-matrix/index.html#abstract__red-hat-el-kvm | |
| 08:37:54 | ykarel | ralonsoh, sean-k-mooney but we still hit kernel panic with those 0.6.2 qcow images, i think i have never seen that issue with uec images | |
| 08:37:55 | ykarel | https://32b7a8914f85d2150a67-dfd2b77d4a65df68dc83e2cbebde05a8.ssl.cf1.rackcdn.com/924004/4/check/tempest-full-py3/861ecb0/testr_results.html | |
| 08:39:50 | ykarel | i mean never seen that issue with uec images in neutron jobs that we track | |
| 08:41:08 | ralonsoh | ykarel, we can also add https://review.opendev.org/c/openstack/nova/+/924746/2 in our jobs | |
| 08:41:55 | ykarel | ralonsoh, yeap +1 to that as we should also avoid those random kernel panics in our jobs | |
| 08:42:28 | ralonsoh | ykarel, perfect, I | |
| 08:42:34 | ralonsoh | I'll change the neutron patch | |
| 09:02:31 | opendevreview | Mark Goddard proposed openstack/nova master: ironic: Let Ironic handle deployment cleanup actions during destroy https://review.opendev.org/c/openstack/nova/+/883411 | |
| 09:04:13 | sean-k-mooney | ykarel: we have see that issue with the uec images, when we swapped to them the kernel panices reduced but they never went away | |
| 09:05:16 | sean-k-mooney | ykarel: i will also poitn out that creating vms with uec images is not how 99% of people use openstack | |
| 09:06:06 | sean-k-mooney | its why nova in particaly cant just use uec images even if that was a 100% reliable solution which it is not. | |
| 09:38:53 | frickler | sean-k-mooney: iiuc the 2024.1 fix is blocked by https://review.opendev.org/c/openstack/nova/+/923831 now? so it could be rebase on top of it to get the tests to pass and reviewers could approve things in parallel? | |
| 09:41:05 | sean-k-mooney | its not blocked | |
| 09:41:11 | sean-k-mooney | frickler: well it is | |
| 09:41:16 | sean-k-mooney | but rebasing is not the answer | |
| 09:41:23 | sean-k-mooney | we can merge https://review.opendev.org/c/openstack/nova/+/923831 | |
| 09:41:26 | sean-k-mooney | and then just rehceck | |
| 09:42:02 | sean-k-mooney | i woudl prefer to not have to respin the cherrypics for the sha but i can if needed | |
| 09:42:11 | frickler | which takes more time than to rebase now. so anyway, bauzas gibi could you look at ^^ please | |
| 09:43:09 | sean-k-mooney | frickler: i was about to ping bauzas, gibi is on pto today but i thinke we can proceed with this without there review | |
| 09:44:22 | frickler | yeah, sorry for being impatient, I was just hoping that with just a single commit per branch this whole thing would be done within hours and not take days again | |
| 09:45:07 | sean-k-mooney | frickler: well that why i started backporting https://review.opendev.org/c/openstack/nova/+/923831 2 weeks ago | |
| 09:45:34 | sean-k-mooney | i had hoped ot have that in place before this hit | |
| 09:45:57 | sean-k-mooney | the prvious cve was also impacted by theuse of the uec images | |
| 09:46:30 | sean-k-mooney | but that ended up bing partly mitigated | |
| 10:01:07 | ykarel | sean-k-mooney, ack atleast in our jobs we have not reproduced that issue with uec image | |
| 10:06:44 | frickler | sean-k-mooney: I noticed that I do have stable core powers, so added +2, but leaving the approval for you | |
| 10:13:25 | sean-k-mooney | ill give bauzas an hour or so and move forward if he or stephenfin dont have time to review https://review.opendev.org/c/openstack/nova/+/923831 by noon(utc+1) | |
| 10:16:08 | bauzas | here now | |
| 10:17:10 | bauzas | https://review.opendev.org/c/openstack/nova/+/923831 +Wd | |
| 10:17:22 | sean-k-mooney | bauzas: thanks | |
| 10:49:08 | opendevreview | Michael Still proposed openstack/nova master: libvirt: Add config option to require secure SPICE. https://review.opendev.org/c/openstack/nova/+/922544 | |
| 10:49:09 | opendevreview | Michael Still proposed openstack/nova master: libvirt: allow concurrent access to SPICE consoles. https://review.opendev.org/c/openstack/nova/+/922546 | |
| 10:49:09 | opendevreview | Michael Still proposed openstack/nova master: WIP: libvirt: Add guest devices to support SPICE USB. https://review.opendev.org/c/openstack/nova/+/922547 | |
| 10:49:10 | opendevreview | Michael Still proposed openstack/nova master: WIP: libvirt: Optionally enable SPICE debug logging. https://review.opendev.org/c/openstack/nova/+/922548 | |
| 10:49:10 | opendevreview | Michael Still proposed openstack/nova master: WIP: libvirt: Optionally support sound when using SPICE. https://review.opendev.org/c/openstack/nova/+/922549 | |
| 10:49:11 | opendevreview | Michael Still proposed openstack/nova master: libvirt: allow direct SPICE connections to qemu https://review.opendev.org/c/openstack/nova/+/924844 | |
| 10:49:44 | mikal | sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/924844/1 is my first swing at the reworking of the Nova APIs for the SPICE consoles. | |
| 10:51:12 | sean-k-mooney | mikal: stephenfin is working on a paralle series to add openapi schema validation that might collide with that by the way but we can cross that bridge wehn we get there | |
| 10:51:55 | mikal | sean-k-mooney: yeah, fair enough. Imma just gonna keep rebasing and uploading for now. | |
| 10:53:38 | sean-k-mooney | mikal: currently my focuse is unfortuentlly on backporting a cve fix upstream and downstream so while i skimmed that i proably wont be able to start reviewing properly unitl next week | |
| 10:53:41 | mikal | sean-k-mooney: assuming that the bottom three of those pass CI (and the first two already have before), I'll move onto reimplementing the sound model as an extra spec next. There is also a patch in that stack which adds USB redirect devices, I am undecided if I should make the number of devices configurable in extra specs as well. | |
| 10:53:51 | sean-k-mooney | hopefullly we will get most of the cve patches landed today | |
| 10:54:39 | mikal | sean-k-mooney: yeah fair enough, I'm just a bit concerned about the code complete deadline, so I want to get them out there as quick as I can. | |
| 10:54:40 | sean-k-mooney | we make the number of serial ports configurable in the flavor extra specs and image properlteis i belive | |
| 10:54:47 | sean-k-mooney | so i dont see a harm in supproting bot | |
| 10:55:13 | sean-k-mooney | i.e. supportign usb count in both flavor and image | |
| 10:55:30 | mikal | I haven't read https://review.opendev.org/c/openstack/nova-specs/+/920687 in depth yet, but I will do so before doing any USB stuff which might conflict. | |
| 10:55:34 | sean-k-mooney | jsu tmake sure if they disagree that you raise a falvor_image_configlct exctption in the api properly | |
| 10:55:51 | mikal | Is there a good example of a previous extra spec which does what you want that I can cargo cult? | |
| 10:56:35 | sean-k-mooney | mikal: am yes i can proably find one. likely the vPMU or vIOMMu ones | |
| 10:56:45 | sean-k-mooney | one sec ill grab the relevent review | |
| 10:57:05 | mikal | sean-k-mooney: ok cool. No rush though, its basically my bed time so I wont look at this until tomorrow morning your time anyways. | |
| 10:57:49 | sean-k-mooney | mikal: as prior arut to allwoign it to be set in flavor i woudl sight https://github.com/openstack/nova/blob/master/nova/api/validation/extra_specs/hw.py#L448-L459 as evidnce :) | |
| 10:58:47 | sean-k-mooney | mikal: https://github.com/openstack/nova/commit/326bc658eef04576230d5ba90d2a02bf32deee03 | |
| 10:59:25 | sean-k-mooney | mikal: that predates the flavor extra spec validation feature by the way | |
| 10:59:56 | mikal | sean-k-mooney: oh, that makes me realise I probably should have written release notes for these changes... | |
| 11:00:21 | sean-k-mooney | mikal: so when addign flavor extra specs please make sure you add a vlaidator too | |
| 11:00:53 | sean-k-mooney | mikal: yes you have two options on that front. start a singel releasenote in the base patch that has a useable feature and update it in the rest | |
| 11:01:15 | sean-k-mooney | or have a sperate release note for each seperate adddtion of funcitonality | |
| 11:01:26 | mikal | sean-k-mooney: yeah, that's not going to happen tonight. That can be tomorrow Michael's problem. | |
| 11:01:33 | sean-k-mooney | :) | |
| 11:02:01 | sean-k-mooney | we sometimes put hte release not in the api patch that enabels the fucntionaltiy, we normlaly keep that to the end of the series by the way | |
| 11:02:03 | mikal | Either way I'd appreciate feedback, but I get that you're busy. I'll do release notes tomorrow before I move onto extra specs etc. | |
| 11:02:54 | sean-k-mooney | mikal: well the main feedback is you put the api change before the dirver change that implemted the feature | |
| 11:02:58 | sean-k-mooney | that is the wrogn order | |
| 11:03:03 | mikal | In my head the remaining patches (after the first three) are "more optional". You can live without USB redirection and sound if you need to. The feature is still useful to some people without those. | |
| 11:03:16 | sean-k-mooney | you need to put the api change at the end because once the api is intoduced the feature shoudl be useable fully | |
| 11:03:42 | sean-k-mooney | oh actully | |
| 11:03:49 | mikal | The feature should be fully usable after patch three. | |
| 11:03:57 | sean-k-mooney | ok ya i see | |
| 11:04:09 | mikal | (Technically patch 3 would work on its own, but the others were already up there). | |
| 11:04:16 | sean-k-mooney | the rest are sound, debuging and usb | |
| 11:04:22 | sean-k-mooney | ok then its fine as is | |
| 11:04:26 | mikal | Yeah, and I might drop debugging. I am undecided. | |
| 11:04:53 | sean-k-mooney | it proably does not need seperate debug log cofnig form our normal debug config | |
| 11:04:54 | mikal | Its so verbose (and so weird because its GTK debugging) that its useful sometimes, but you have to be quite sad to turn it on. | |
| 11:05:00 | sean-k-mooney | unless your very very verbose | |
| 11:05:09 | mikal | Its very very verbose debugs in the libvirt qemu logs. | |
| 11:05:26 | mikal | Its orchestrating qemu to write debug logs, not nova. | |
| 11:05:54 | mikal | It helped when I was reverse engineering some bits of the protocol and occasionally crashing the hypervisor. | |
| 11:06:02 | sean-k-mooney | mikal: oh ... | |
| 11:06:17 | sean-k-mooney | you are aware we don not allow wemu command line options to be used in nova right | |
| 11:06:21 | mikal | The SPICE protocol docs are... not good. | |
| 11:07:16 | mikal | sean-k-mooney: as in what happens in https://review.opendev.org/c/openstack/nova/+/922546/5/nova/virt/libvirt/config.py is banned? | |
| 11:07:20 | sean-k-mooney | so we cant procedd with https://review.opendev.org/c/openstack/nova/+/922546/5/nova/virt/libvirt/config.py | |
| 11:07:44 | mikal | That is a shame, because that feature is cool. | |
| 11:07:57 | mikal | But libvirt only exposed it as a command line flag. | |
| 11:08:12 | sean-k-mooney | then we need a livbirt chagne before we can support configuing tha tin nova | |
| 11:08:22 | sean-k-mooney | i have unfrutaly had to do that dance several times | |
| 11:08:24 | mikal | Its this -- https://www.spice-space.org/multiple-clients.html | |
| 11:09:01 | sean-k-mooney | if we use the qemu command elemets directly it marks the domain as tainted and voids all supprot form most distors virt teams | |
| 11:09:19 | sean-k-mooney | as a result we have had a strict ban on it upstream for as long as i have worked on openstack | |
| 11:09:38 | mikal | I thought secure boot required it too though? | |
| 11:09:45 | sean-k-mooney | nope | |