| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-23 | |||
| 13:04:21 | opendevreview | Felix Huettner proposed openstack/nova stable/queens: Gracefull recovery when attaching volume fails https://review.opendev.org/c/openstack/nova/+/830602 | |
| 13:05:43 | gibi | yuval: I'm +2 | |
| 13:10:43 | gibi | sean-k-mooney: I think pedro answered your question here https://review.opendev.org/c/openstack/nova/+/828387 | |
| 13:26:18 | sean-k-mooney | they responded but didnt really adress my concern | |
| 13:27:47 | sean-k-mooney | gibi: we could proceed with this update but i think this has the inverse problem | |
| 13:28:17 | sean-k-mooney | the old doc described live_migration_downtime as the maxium but failed to capture it was best effort | |
| 13:28:37 | sean-k-mooney | the new docs to me at least imples that live_migration_downtime is the minium downtime and it can be larger | |
| 13:29:52 | sean-k-mooney | to me live_migration_downtime is the maxium downtime we have asked libvirt to not exceed but its best effort | |
| 13:30:08 | sean-k-mooney | so it shoudl be less then that but in some case may be larger | |
| 13:30:51 | gibi | I see | |
| 13:31:10 | gibi | you are right | |
| 13:49:01 | sean-k-mooney | gibi: so i doen know if we want to merge the update as is or rephrase | |
| 13:49:16 | kashyap | gibi: Very clear analysis in the bug; nice work! To tie up the loose end, they're temporarily going to skip it - https://review.opendev.org/c/openstack/openstack-tempest-skiplist/+/828243 | |
| 14:00:10 | opendevreview | Merged openstack/nova master: VmWare: Remove unused legacy_nodename regex https://review.opendev.org/c/openstack/nova/+/806336 | |
| 14:04:16 | opendevreview | Rajat Dhasmana proposed openstack/nova master: Add support for volume backed server rebuild https://review.opendev.org/c/openstack/nova/+/820368 | |
| 14:12:49 | pmonteir | pedro ans | |
| 14:13:07 | pmonteir | ops, sry | |
| 14:27:17 | opendevreview | Pedro Monteiro Azevedo de Moura Almeida proposed openstack/nova master: Update live_migration_downtime definition https://review.opendev.org/c/openstack/nova/+/828387 | |
| 14:33:17 | pmonteir | sean-k-mooney: hey, saw u and gibi were talking about the change above today and I agree with the comment u left there, I didn't understand what u meant in the first comment, but got it now! If u can take a look when u have some time, pls do :D | |
| 14:35:28 | gibi | pmonteir: sure, I will check | |
| 14:51:01 | pmonteir | thank you! :) | |
| 14:55:29 | sean-k-mooney | pmonteir: thanks im fine with the new wording so +2 | |
| 15:01:21 | gibi | pmonteir: then it is approved :) | |
| 15:04:15 | mfo | hey folks! i'm looking for patch reviewers/feedback for bug 1960758, if you have a chance :) thanks in advance! | |
| 15:04:22 | mfo | https://bugs.launchpad.net/nova/+bug/1960758 | |
| 15:04:35 | mfo | (UEFI libvirt servers can't boot on Ubuntu 20.04 hypervisors with Ussuri/Victoria) | |
| 15:08:00 | pmonteir | thanks for the answering so quickly, guys! :) | |
| 15:09:52 | opendevreview | Felix Huettner proposed openstack/nova stable/queens: Gracefull recovery when attaching volume fails https://review.opendev.org/c/openstack/nova/+/829861 | |
| 15:10:44 | dansmith | bauzas: do you have opinions on my comment about splitting this up? https://review.opendev.org/c/openstack/nova/+/820368/8 | |
| 15:10:57 | dansmith | bauzas: it's huge right now, in terms of what all it touches | |
| 15:11:02 | bauzas | dansmith: looking | |
| 15:11:14 | dansmith | I can help him split it if you think it's important, but if I'm the only one I'll shut up | |
| 15:12:08 | bauzas | dansmith: nah, I agree with you | |
| 15:12:10 | sean-k-mooney | mfo:i think we alredy fixed this | |
| 15:12:29 | bauzas | adding a microversion plus a new event by the same change is large | |
| 15:12:53 | dansmith | bauzas: okay, can you slap a quick comment on there? I'll work with him to split after the next rev | |
| 15:13:06 | dansmith | bauzas: I assume this is still on the slate for merging yeah? | |
| 15:13:12 | bauzas | dansmith: doing it nbow | |
| 15:13:20 | dansmith | bauzas: <3 | |
| 15:13:27 | sean-k-mooney | mfo: teh secvure boot firemware shoudl not require secure boot to function it just supports it | |
| 15:13:56 | sean-k-mooney | mfo: so nova should not need to have any logic to select the non secure boot version | |
| 15:14:37 | sean-k-mooney | mfo: i aslo done se any fix againt master | |
| 15:14:51 | bauzas | dansmith: done | |
| 15:14:59 | dansmith | thanks | |
| 15:15:01 | bauzas | I explained why it's important to split | |
| 15:15:03 | sean-k-mooney | you seam to have started with a sable only patch https://review.opendev.org/c/openstack/nova/+/828980 | |
| 15:15:20 | sean-k-mooney | which i dont think is correct | |
| 15:18:40 | mfo | sean-k-mooney, thanks for looking. i'll follow up on the sec boot firmware (no) needs that you mentioned. and this is "fixed" on wallaby and later/master w/ the implementation of secboot spec/support, due a refactor (this a bit buried in the commit msg, but the research has been done to go w/ stable-only. :) | |
| 15:19:22 | mfo | and, seconding pmonteir above, thx for answering so quickly! | |
| 15:19:28 | sean-k-mooney | mfo: the secure booth ovmf image shoudl work without secure boot enabled howevdr | |
| 15:19:59 | sean-k-mooney | we should not need to filter like this form my understandig | |
| 15:20:06 | sean-k-mooney | do you know why this is requried | |
| 15:20:18 | mfo | ack, i'll be following up on that. | |
| 15:20:55 | sean-k-mooney | if we can get a statement as to why this is requried we could proably proceed with the minimal stabel only backport | |
| 15:21:11 | sean-k-mooney | but that obviouly has risk too | |
| 15:21:28 | sean-k-mooney | i agree that backportign the secure boot feature is likely not viable | |
| 15:22:25 | mfo | er, it was my assumption that it didn't work bcz of secboot ovmf image requirements; but per your statement, it might as well be something w/ ubuntu's qemu or ovmf pkgs. which i'll go check/debug further on why secboot.fd isn't booting. | |
| 15:22:32 | sean-k-mooney | but we woudl at least need som unit tests to vover this change | |
| 15:24:33 | mfo | sean-k-mooney, understood. you mean something like just booting VMs in bios and uefi mode, or something more specific like checking the rendered libvirt xml and check for the ovmf image used too? | |
| 15:25:02 | sean-k-mooney | so to test https://review.opendev.org/c/openstack/nova/+/828979/2/nova/virt/libvirt/driver.py#5834 | |
| 15:25:19 | sean-k-mooney | we should ensure in a unit test that we include a ovm path that has .secboot.fd | |
| 15:25:30 | sean-k-mooney | as the first option | |
| 15:25:38 | sean-k-mooney | and that the non secboot.fd path is chosen | |
| 15:25:59 | sean-k-mooney | we should also check what appens if all the path have secboot.fd | |
| 15:26:31 | sean-k-mooney | also i wonder if all distos use the same nameing convention | |
| 15:27:11 | mfo | got it. | |
| 15:27:32 | chateaulav | so i have additional package installs defined in the stack.sh for my proposed CI to ensure devstack has the supported requirements. is that the correct place or is there a better method due to how it builds. these only need installed on the compute | |
| 15:27:35 | opendevreview | Rajat Dhasmana proposed openstack/python-novaclient master: Add parameter to rebuild boot volume https://review.opendev.org/c/openstack/python-novaclient/+/827163 | |
| 15:29:06 | mfo | sean-k-mooney, since we're testing against a limited option set (the hardcoded paths array), there's only that nameing convention to check (if i got your point right :) | |
| 15:29:25 | bauzas | wow, time flies and I'm on the policy changes | |
| 15:29:28 | bauzas | ... | |
| 15:31:15 | sean-k-mooney | mfo: so on centos 9 there is no version aviiable without secureboot form the set | |
| 15:31:49 | sean-k-mooney | '/usr/share/OVMF/OVMF_CODE.secboot.fd' is the only one of the 3 that is present | |
| 15:32:30 | sean-k-mooney | mfo: there is a singel non secureboot capable image at /usr/share/edk2/ovmf/OVMF_CODE.cc.fd | |
| 15:32:35 | sean-k-mooney | but that will not be checked | |
| 15:33:12 | mfo | sean-k-mooney, ok. so, if for some reason that patch is still required, we're better checking if there's another option available before ignoring secboot.fd. | |
| 15:33:27 | sean-k-mooney | yes | |
| 15:33:44 | sean-k-mooney | so redhat will be releaseign osp 17 based on stable wallaby on rhel 9 later this year | |
| 15:34:05 | sean-k-mooney | and the current patch would break uefi i belive in that case | |
| 15:34:32 | sean-k-mooney | however i dont know if we have the same issue where we woudl need to use the '/usr/share/OVMF/OVMF_CODE.fd' image if secure boot is not requested | |
| 15:34:52 | bauzas | gmann: around ? | |
| 15:34:56 | bauzas | or maybe dansmith ? | |
| 15:34:59 | bauzas | context is https://review.opendev.org/c/openstack/nova/+/828670/4/nova/api/openstack/compute/server_groups.py | |
| 15:35:08 | gmann | bauzas: hi | |
| 15:35:11 | bauzas | we'll change the API behaviour | |
| 15:35:27 | bauzas | as you need to be in the right project to getting the server groups | |
| 15:35:32 | mfo | hmm, but this isnt an issue in wallaby, right? as it uses a diff method to pick the ovmf files, based on descriptor files from qemu (eg, /usr/share/qemu/firmware/) | |
| 15:35:32 | bauzas | it's OK for me | |
| 15:35:33 | bauzas | but, | |
| 15:35:41 | mfo | sean-k-mooney, ^ | |
| 15:35:50 | dansmith | bauzas: that's *your* project id | |
| 15:36:02 | bauzas | given it will change the behaviour, do we all agree we don't need a microversion ? | |
| 15:36:06 | dansmith | bauzas: so it should be no different than today | |
| 15:36:20 | bauzas | dansmith: well, | |
| 15:36:27 | sean-k-mooney | mfo: ack ya it might not be an issue there | |
| 15:36:30 | bauzas | previously you were giving none as a value | |
| 15:36:33 | mfo | sean-k-mooney, ok cool. | |
| 15:36:36 | sean-k-mooney | as you said its using a differnt method | |
| 15:36:49 | sean-k-mooney | but we need tobe careful not to break other distors is my point | |
| 15:36:49 | bauzas | dansmith: tomorrow, you'll get an exception, right? | |