| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-07-07 | |||
| 22:16:05 | sean-k-mooney | that woudl not be so terrible i gues.. allow them ot updload somethign to barbican and pass a refence ot it when booting and have nova inject it into the tpm usign the users token ot retirve it | |
| 22:16:08 | mikal | sean-k-mooney: noting that I've never managed to find a good guide to TPM stuff and am therefore a noob, why would the hypervisor generating a unique certificate that identifies the instance and storing it in the TPM so inside the instance can sign things but not actually get to the certificate not be secure? Isn't that almost exactly what the | |
| 22:16:08 | mikal | firmware is doing, just with a CA for the cloud instead of a CA for jus the TPM? | |
| 22:17:12 | mikal | sean-k-mooney: understanding TPMs is also on my todo list of things I'll never get around to. | |
| 22:18:03 | sean-k-mooney | main thing to under stand to day is we cant live migrate with tpms to day because we encypt them with a secreate stored in barbican that only the user that create the vm can acess :) so tpms equal pain | |
| 22:19:05 | sean-k-mooney | we coudl likely generate a cert to "sign" or attest the identiy of the vm, and maybe put that in the config drive or tpm for you to atteset | |
| 22:19:27 | sean-k-mooney | but im not sure we could use that for auth | |
| 22:20:14 | sean-k-mooney | that was one of the jwt propsoals that was made not too long ago. inject a jwt token purly for attestation of the identiy of the sever but not for actual keystone auth usage | |
| 22:21:53 | sean-k-mooney | mikal: https://github.com/bbc/nova/commit/382984a3a23032c96089cb5877a55e425db7cee4 | |
| 22:25:13 | mikal | sean-k-mooney: so that injected JWT has a name in SPIFFE that I've forgotten, but its a definitely a thing they do. Then again, how do you handle the JWT expiring for long lived VMs? | |
| 22:27:33 | sean-k-mooney | mikal: no idea the bbc impleaiton was just an experiment and it never landed upstream | |
| 22:28:41 | mikal | https://kasm.stillhq.com/#/session/9606cb74-10e3-4e1e-8990-0779495f79dd -- SPIFFE calls it a SVID apparently. | |
| 22:30:37 | mikal | Ugh, wrong url. | |
| 22:30:53 | mikal | https://github.com/spiffe/spiffe/blob/main/standards/JWT-SVID.md this one. | |
| #openstack-nova - 2025-07-08 | |||
| 08:37:37 | mhen | Hi! #openstack-placement seems to be empty. Is this the right channel for Placement? | |
| 09:19:07 | gibi | mhen: yes it is the right one | |
| 09:20:37 | mhen | I've got a question regarding Placement: | |
| 09:20:45 | mhen | is my interpretation correct that Placement offers no means of adjusting its WSGI pipeline? It seems hardcoded here: https://github.com/openstack/placement/blob/ce677d96f2a5e18dcc5e10a2046cac9780a67cde/placement/deploy.py#L108-L117 | |
| 09:20:47 | opendevreview | Kamil Sambor proposed openstack/nova master: Switch from Eventlet timeout https://review.opendev.org/c/openstack/nova/+/954324 | |
| 09:21:00 | mhen | For other services, there is usually an api-paste.ini or something similar. | |
| 09:21:12 | mhen | So the audit middleware (https://docs.openstack.org/keystonemiddleware/latest/audit.html) cannot be used with Placement? | |
| 09:23:37 | gibi | mhen: good question let me double check | |
| 09:24:34 | gibi | mhen: it seems you are right we have a hard coded pipeline with no api-paste configuratbility | |
| 09:27:50 | mhen | alright, thanks for confirming | |
| 12:51:48 | opendevreview | Balazs Gibizer proposed openstack/nova master: [pci]Keep used dev in Placement regardless of dev_spec https://review.opendev.org/c/openstack/nova/+/954149 | |
| 12:51:48 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reproduce bug/2115905 https://review.opendev.org/c/openstack/nova/+/954336 | |
| 13:25:51 | sean-k-mooney | gibi: i reviewed the first couple of patches in your eventlet work and im back up to where i left off before (the stats priting one) for the most part they look fine to me | |
| 13:27:16 | sean-k-mooney | i also looked at kamils patch, https://review.opendev.org/c/openstack/nova/+/949754/17 i think ThreadingEventWithResult should just be a future not a event with a result, i woudl be interested to know if you agree but i left that as a comment in gerrit so no rush | |
| 13:56:05 | zigo | Hi there! I filled-up a new bug: https://bugs.launchpad.net/nova/+bug/2116186 | |
| 13:56:05 | zigo | I tried using an older version of pymysql (the one in Bookworm), it didn't help. I tried doing a gc.disable() to check if that was another instance of the GC issue in Python 3.13, and it didn't help either. Anyone has an idea of what's going on? | |
| 13:59:07 | gibi | sean-k-mooney: on the ThreadingEventWithResult: I wanted a solution that changes as minimal in the current flow of the code as possible. Hence the direct replication of the Eventlet.Event behavior with threading.Event + a variable approach. The Future based approach has the drawback in my mind that the concurrent Future interface explicitly says that setting the result of the Future should happen by | |
| 13:59:13 | gibi | the implementation of an Executor. So it seems using a Future in that nova code would create a lot more code churn if it is even possible. | |
| 13:59:50 | sean-k-mooney | am so future are usabel with raw thread | |
| 13:59:58 | sean-k-mooney | so an executor is not stritly required | |
| 14:00:14 | gibi | https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Future.set_result | |
| 14:00:33 | gibi | This method should only be used by Executor implementations and unit tests. | |
| 14:01:11 | sean-k-mooney | hum | |
| 14:01:22 | sean-k-mooney | that does not conform to what i would normally consider a future then | |
| 14:02:17 | sean-k-mooney | we would have to use a queue isnterad which is less obvious | |
| 14:03:43 | gibi | we started with a queue actually :) If you look back of previous PSs it is there | |
| 14:04:17 | sean-k-mooney | to me a future is concpetiulaly the same as a a queue of lenth 1 with blocking or non blocking gets dependign on if you pass a timeout to result | |
| 14:04:18 | gibi | then we learned that eventlet.Event has the behavior that it sends the same piece of result to all waiters so a queue with a lenght of 1 is not optimal | |
| 14:04:34 | sean-k-mooney | ah i see | |
| 14:04:40 | gibi | as it requires requeueing the same result :/ | |
| 14:05:02 | sean-k-mooney | well that fan out or multi subsciber behaivor seams non standard too | |
| 14:05:07 | gibi | yep it is not | |
| 14:05:13 | sean-k-mooney | are we actuly reallying on that | |
| 14:05:27 | sean-k-mooney | i think for now im ok with the current approch then | |
| 14:05:34 | gibi | I'm not sure but I'm not willing to risk | |
| 14:05:40 | sean-k-mooney | but we may want to see if we can simplicy in the future | |
| 14:05:50 | gibi | yepp simplifying in the future is the way | |
| 14:06:05 | gibi | first have something that works and then optimize | |
| 14:10:37 | sean-k-mooney | so the asyncio future does nto have that limiation for what its worth | |
| 14:10:39 | sean-k-mooney | https://docs.python.org/3/library/asyncio-future.html#asyncio.Future.set_result | |
| 14:12:47 | sean-k-mooney | i ws not expectign thos to diverge in that regard | |
| 14:16:55 | gibi | yeah it is strange | |
| 14:22:46 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reproduce bug/2115905 https://review.opendev.org/c/openstack/nova/+/954336 | |
| 14:22:47 | opendevreview | Balazs Gibizer proposed openstack/nova master: [pci]Keep used dev in Placement regardless of dev_spec https://review.opendev.org/c/openstack/nova/+/954149 | |
| 14:23:59 | sean-k-mooney | looking at https://peps.python.org/pep-3148/ i think the landed on the current interface by emulating the java and in https://peps.python.org/pep-3156/#futures the intentioally diverged | |
| 14:25:13 | sean-k-mooney | anyway that enough of a distaction | |
| 15:02:09 | Uggla | Nova meeting in ~1h | |
| 15:31:16 | gmaan | Uggla: Due to Board meeting, I might not be able to join today meeting. | |
| 15:31:28 | Uggla | gmaan, ok | |
| 15:31:40 | Uggla | gmaan, thanks for the notification | |
| 15:34:40 | gibi | I know Dan is out this week, so we might have a quick meeting if no quorum is present | |
| 16:00:14 | Uggla | #startmeeting nova | |
| 16:00:14 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:14 | opendevmeet | Meeting started Tue Jul 8 16:00:14 2025 UTC and is due to finish in 60 minutes. The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:00:14 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:24 | Uggla | Hello everyone | |
| 16:01:07 | fwiesel | o/ | |
| 16:01:21 | elodilles | o/ | |
| 16:03:04 | bauzas | o/ | |
| 16:03:14 | Uggla | Let's start slowly so people could join | |
| 16:03:23 | Uggla | #info No Critical bug | |
| 16:03:35 | Uggla | oops | |
| 16:03:37 | Uggla | #topic Bugs (stuck/critical) | |
| 16:03:48 | Uggla | #info No Critical bug | |
| 16:03:57 | Uggla | #topic Gate status | |
| 16:04:04 | Uggla | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | |
| 16:04:12 | Uggla | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | |
| 16:04:21 | Uggla | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status | |
| 16:04:28 | Uggla | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:04:35 | Uggla | #info Please try to provide a meaningful comment when you recheck | |
| 16:04:50 | Uggla | #info https://bugs.launchpad.net/nova/+bug/2115980 opened by gibi. It seems nova next has regular failure due to this. | |
| 16:05:17 | Uggla | gibi, do you have more info about ^ | |
| 16:05:53 | clarkb | the underlying issue is that zuul launcher can in some exceptional circumstances assign nodes to multiple providers within the same nodeset. This is due to zuul launcher wanting to be able to support k8s pods and openstack vms in the same nodeset | |
| 16:06:19 | clarkb | unfortauntely there were a few bugs (I think 2 or 3 at this point) that allowed it to mix providers more often than expected. The last of these known bugs was fixed around 2200UTC yseterday | |
| 16:06:35 | gibi | yepp the latest from me is that I'm not seeing the failure today any more | |
| 16:06:41 | clarkb | with each of the bugfixes the occurence of this issue should be lessened. And hopefully if we've fixed the bugs then the issue goes away | |
| 16:07:08 | gibi | I will keep the bug around for couple of days then I will close it if the problem does not re-occure | |
| 16:08:03 | Uggla | thanks clarkb, I appreciate your inputs. | |
| 16:08:33 | Uggla | thanks gibi | |
| 16:08:51 | Uggla | skipping next topic because gmann is not available. | |
| 16:09:08 | Uggla | #topic Release Planning | |
| 16:09:17 | Uggla | #link https://releases.openstack.org/flamingo/schedule.html | |
| 16:09:25 | Uggla | #info Nova deadlines are set in the above schedule | |
| 16:09:50 | Uggla | Spec freeze was last week. So no new specs. | |
| 16:10:15 | Uggla | #topic Review priorities | |
| 16:10:31 | Uggla | #link https://etherpad.opendev.org/p/nova-2025.2-status | |