| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-28 | |||
| 16:10:14 | bauzas | #endmeeting | |
| 16:10:17 | bauzas | even | |
| 16:11:32 | gibi | have a nice evening folks | |
| 16:11:39 | elodilles | you too o/ | |
| 16:15:30 | Uggla | bauzas, already done ! | |
| 16:15:51 | bauzas | Uggla: yeah we didn't had a quorum | |
| 16:16:16 | Uggla | oh ok. | |
| 16:27:35 | opendevreview | Merged openstack/osc-placement master: Replace deprecated assertRaisesRegexp https://review.opendev.org/c/openstack/osc-placement/+/817365 | |
| 16:55:51 | bauzas | gibi: sean-k-mooney: Uggla: others: I forgot to tell I'll be on PTO tomorrow | |
| 16:57:38 | sean-k-mooney[m] | ok | |
| 19:47:27 | opendevreview | Dan Smith proposed openstack/nova master: WIP: Remove system scope from all APIs https://review.opendev.org/c/openstack/nova/+/848021 | |
| 19:47:45 | dansmith | gmann: ^ passes unit tests locally for me, we'll see what happens in functional | |
| 19:47:54 | dansmith | also, side note | |
| 19:48:05 | dansmith | I'm f**king tired of policy stuff | |
| 19:49:18 | gmann | dansmith: thanks for that. I was also fixing some unit tests but functional test will be good i think. | |
| 19:49:30 | gmann | dansmith: agree, same here on policy stuff. | |
| 19:49:42 | dansmith | ack, it would be GREAT if I don't have to mess with functional failures | |
| #openstack-nova - 2022-06-29 | |||
| 07:25:01 | gibi | bauzas: enjoyt | |
| 18:01:25 | opendevreview | Mauricio Faria de Oliveira proposed openstack/nova stable/victoria: [stable-only] libvirt: UEFI: pc: prefer non-secureboot loaders https://review.opendev.org/c/openstack/nova/+/828979 | |
| 18:05:43 | mfo | dansmith, implemented your suggestions/patch approach from some time ago ^ for when / if you have a chance; this is not urgent at all. thanks! | |
| 18:07:16 | dansmith | mfo: okay, all that context has dropped out of my head in the months since we had that, but.. will add it to the list | |
| 22:08:09 | opendevreview | melanie witt proposed openstack/nova master: Test attached volume extend actions in the nova-next job https://review.opendev.org/c/openstack/nova/+/843700 | |
| #openstack-nova - 2022-06-30 | |||
| 07:32:45 | gibi | good morning | |
| 08:10:23 | bauzas | good morning | |
| 08:10:59 | bauzas | gibi: actually, yesterday I was organizing a birthday party for my daughter with 8 of her friends :) | |
| 08:11:24 | bauzas | not sure I "enjoyed" it :D | |
| 08:31:00 | Uggla | bauzas, still alive ? :) | |
| 09:57:17 | gibi | bauzas, Uggla: https://www.youtube.com/watch?v=qdrs3gr_GAs ? :) | |
| 11:36:39 | sean-k-mooney | gibi: portal is a great game | |
| 11:36:48 | gibi | indeed | |
| 11:37:00 | sean-k-mooney | by the way i watched your summit video | |
| 11:37:09 | sean-k-mooney | live demos are fun | |
| 11:37:21 | sean-k-mooney | did you restack live on stage | |
| 11:37:37 | sean-k-mooney | you said you rebooted the vm but devstack does not survie reboots anymore | |
| 11:37:57 | sean-k-mooney | since there are ordering issues with the systemd service files | |
| 11:54:10 | gibi | I restarted the devstack VM, but did not restack it. It worked:D | |
| 11:59:35 | sean-k-mooney | maybe the issues have been fixed | |
| 12:00:12 | sean-k-mooney | the wsgi service used to race with appache i think and there was an issue with the /run dirs being created | |
| 12:00:21 | sean-k-mooney | you could get lucky | |
| 12:00:34 | sean-k-mooney | but often the service woudl not start cleanly | |
| 12:05:25 | gibi | I never seen that issue locally | |
| 12:05:31 | gibi | but meh | |
| 12:06:31 | sean-k-mooney | its been a while since i tried it honestly | |
| 12:06:47 | sean-k-mooney | like 18.04 era | |
| 13:44:43 | sean-k-mooney | bauzas: was i imaginign it or did you have an implementation of removing the ssh key pair generation | |
| 13:44:55 | sean-k-mooney | bauzas: i was going to go review it today but i cant find it | |
| 13:45:23 | sean-k-mooney | bauzas: i was hopign we could get that closed out to remove it form the list of thing we need to finish this cycle | |
| 13:46:39 | sean-k-mooney | bauzas: speaking of things i would like to clsoe out can you review https://review.opendev.org/c/openstack/nova/+/847001 | |
| 13:49:03 | sean-k-mooney | gibi: it would be nice if you could reivew this too https://review.opendev.org/c/openstack/nova/+/833411 i would like to keep that backport series moving along | |
| 13:50:15 | gibi | sean-k-mooney: on it | |
| 13:51:34 | sean-k-mooney | thanks | |
| 13:57:45 | sean-k-mooney | im also going to rebase https://review.opendev.org/c/openstack/nova/+/830829 shortly once i run and fix the functional tests | |
| 13:58:08 | sean-k-mooney | tja twill be a nice easy win we defered it last cycle because it was too close to FF | |
| 13:58:23 | sean-k-mooney | so i would like to try an land it by m2 | |
| 13:58:42 | sean-k-mooney | mainly to catch any ci fallout if there is any | |
| 14:01:11 | sean-k-mooney | the benifit of me running test locally on my laptop instead of my home server is it takes a while and i do code reviews while im waiting | |
| 14:02:09 | mfo | dansmith, hey! sorry, i couldn't get back to you yesterday ("context dropped out"). most certainly.. the long delay/lost context is on me :/ | |
| 14:02:19 | mfo | so, briefly: in victoria/ussuri one can set `hw_firmware_type=uefi` and the VM won't boot if the UEFI ovmf firmware/loader picked is the secureboot one (*.secboot.fd), as the default `hw_machine_type=pc` doesn't support it (that needs `q35`). | |
| 14:02:30 | mfo | so we should *try* other firmware/loader files, or use .secboot.fd anyway if its' the only one that exists (not to break/change from what is done in this old/stable branch). | |
| 14:02:41 | mfo | This was a suggestion from sean-k-mooney, and also to have unit tests. | |
| 14:02:47 | mfo | suggestion too). | |
| 14:02:47 | mfo | Your suggestions were 1) to convert the list of firmware/loader paths to constants (so to intentionally "break" any downstream stable consumers that possibly patched that, so they'd be aware of the change and review their version), and 2) change the patch approach to not even iterate the list of firmware/loader files with .secboot.fd if we're on PC machine type. (I just combined it with, "ok, use it if it's the only one" per Sean's | |
| 14:03:51 | mfo | I guess that's what this is about and where we are. :) | |
| 14:03:51 | sean-k-mooney | i think i basicaly said sort so that its last in the list and if its the only one then use it and maybe it will work | |
| 14:03:58 | sean-k-mooney | rahter then deleteing it form the list | |
| 14:04:35 | sean-k-mooney | but yes sercure boot need uefi | |
| 14:04:35 | mfo | sean-k-mooney, yup. this is currently how it is, but the for-loop doesn't have a `break` in case it finds one, so the last file is used. | |
| 14:05:06 | mfo | i could just add a break in there, but this would change things / file end up chosen in the general case, i guess. | |
| 14:05:11 | sean-k-mooney | so it wont work with hw_machine_type=pc` | |
| 14:05:42 | mfo | and for older stable branches, well, i didnt want to risk such changes. (i'm not too familiar w/ openstack yet, actually). | |
| 14:07:14 | sean-k-mooney | i think we aleay want to break on the first file we find that exsits as long as we make the secure boot one last if you did not ask for secure boot | |
| 14:07:47 | sean-k-mooney | we are only going to boot the vm once anyway so there is no point in continuing to check | |
| 14:08:09 | sean-k-mooney | but i dont have your patch open currently so that depnds on how you wrote the loop | |
| 14:09:30 | opendevreview | ribaudr proposed openstack/nova master: Allow unshelve to a specific host (Compute API part) https://review.opendev.org/c/openstack/nova/+/831507 | |
| 14:09:31 | opendevreview | ribaudr proposed openstack/nova master: Allow unshelve to a specific host (REST API part) https://review.opendev.org/c/openstack/nova/+/845897 | |
| 14:10:07 | mfo | right, i wondered why the (existing) loop didn't have a 'break' statement in the first place when it was introduced, but it was long ago, and didn't seem like a thing to change for old stable branches. also, in this version one can't ask for secure boot yet (this is victoria/ussuri, and secureboot came in wallaby), it just happened that a patch adding the OVMF paths included a .secboot.fd file, before proper SB support came in. | |
| 14:11:31 | sean-k-mooney | ack | |
| 14:12:30 | sean-k-mooney | the ovmf frimware images can be build so that secure boot is avaiable but not required | |
| 14:12:46 | sean-k-mooney | so i think the old logic was intended to allow it to be used if it was supproted | |
| 14:12:58 | sean-k-mooney | by the ovmf image by manually configuring it via the boot menu | |
| 14:13:04 | sean-k-mooney | but that was not really supported by nova | |
| 14:13:10 | mfo | sean-k-mooney, ah, i see. | |
| 14:14:19 | mfo | i think that works for the SB feature alone, but i think the SMM feature support once it's built in then it isn't opt-in, right? than that requires support in the emulator (ie, qemu's q35). | |
| 14:14:37 | mfo | s/than/then/ | |
| 14:14:52 | sean-k-mooney | i think that is correct but dont know all the details | |
| 14:15:02 | sean-k-mooney | SMM does require qemu to be configured to enable it | |
| 14:15:23 | sean-k-mooney | but i dont know if you need that enabled if its complied in to the ovmf image | |
| 14:15:41 | mfo | yes, there are many details in this. i added some docs/links to the patch for the research i had done, but it's indeed at the lower-level details. | |
| 14:15:41 | sean-k-mooney | its all a bit of a mess | |
| 14:17:11 | bauzas | sean-k-mooney! sorry, haven't yet done the implementation for the keypair deprecation | |
| 14:19:14 | sean-k-mooney | bauzas: ack no worries i was just expecting that to be relitivly small so if it was off your backlog you woudl have more time to reivew | |
| 14:19:19 | mfo | sean-k-mooney, if you're ever curious, i doc'ed the research details of OVMF/SB/SMM/QEMU in bug 1960758 comment #6, the takeaway is, you can build OVMF with SMM_ENABLE, but then it's not really _secure_ Secure Boot; for that you need SMM_REQUIRE, and then platform support is not optional, it's required as well. | |
| 14:19:52 | sean-k-mooney | bauzas: i was just trying to see if we could reduce context switching by merging some small easy wins before m2 | |
| 14:20:04 | sean-k-mooney | to have less to context switch between coming up to FF | |
| 14:20:48 | sean-k-mooney | mfo: SMM is system management mode support which is actuly unrealted to secure boot | |
| 14:21:54 | sean-k-mooney | SMM is used for some other security feature and ring -2 hypervior feature at run time | |
| 14:21:57 | mfo | sean-k-mooney, IIUIC indeed, it's orthogonal, but it's involved in the implementation of not allowing the OS to tamper w/ the SB things in memory, otherwise the OS could bypass things. | |
| 14:22:12 | mfo | the link to pbonzini's presentation/video about it is really clarifying. | |
| 14:22:42 | sean-k-mooney | yep so in generall i would expect the default uefi image to be build with SMM_ENABLE | |
| 14:22:52 | sean-k-mooney | and the secure boot one to have require | |