Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-07-07
21:44:39 sean-k-mooney we also try to aovid injecting things directly into the image now if we can avoid it
21:45:07 fungi bootstrapping trust is a nontrivial problem
21:45:41 sean-k-mooney yep and the trusted compute folks would go as far as saying proving nvram or other uefi stores is not secure enough
22:02:35 mikal clarkb: other clouds let you do it effectively for any API call.
22:03:02 clarkb ya I know. Its just that is the one example where you can do it with openstack
22:04:58 mikal fungi: this "credential zero" problem is literally what SPIFFE is aimed at. Its just the OpenStack attestor is meh. One day someone should fix it.
22:05:25 mikal Like the hypervisor could produce a certificate for the instance at boot and ram it into the TPM, to my current understanding of TPMs.
22:09:35 fungi yeah, and then the tpm is your implicitly trusted communication channel, albeit one that probably isn't suitable for ramming all the metadata through
22:09:58 fungi but can at least bootstrap a more general-purpose source at that point
22:13:39 sean-k-mooney mikal: so injecting things into tpm would generally not eb considered secure
22:14:10 sean-k-mooney i know you could add a root of turst to teh tpm
22:14:38 sean-k-mooney but if we supprot that soemoen woudl ask to be able to lock that out so that only there root of trust form barbiacn could be injected
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 firmware is doing, just with a CA for the cloud instead of a CA for jus the TPM?
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: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: Reproduce bug/2115905 https://review.opendev.org/c/openstack/nova/+/954336
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
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 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:56:05 zigo Hi there! I filled-up a new bug: https://bugs.launchpad.net/nova/+bug/2116186
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 opendevmeet The meeting name has been set to 'nova'
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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:14 Uggla #startmeeting 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

Earlier   Later