| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-09-30 | |||
| 18:56:13 | sean-k-mooney | melwitt: interesting i had assumed the later that you would be able change via resize | |
| 18:57:46 | melwitt | sean-k-mooney: you mean the former I think :) but yes I also went in with that assumption but I want to pause and make sure that's what we want, bc if we want that, I think we need to not use "image_hw_tpm_secret_security" as the key to stash in the instance sysmeta. bc it makes flavor/resize conflict errors | |
| 18:58:37 | melwitt | (I have been finding things while adding more func tests and tempest tests) | |
| 18:59:04 | melwitt | *flavor/image conflict errors | |
| 18:59:22 | sean-k-mooney | well the flavor image conflcit check shoudl be checkign the glance image keys | |
| 18:59:27 | sean-k-mooney | are we using the stashed copy | |
| 18:59:28 | melwitt | , when the user may not have ever used an image prop | |
| 18:59:44 | sean-k-mooney | i guess we might be to ensure that out of band glance changes dont creap in | |
| 19:00:05 | sean-k-mooney | so we do not need ot use the same key | |
| 19:00:12 | melwitt | we are yeah. for the check virt.hardware.get_tpm_secret_security_constraint() for example | |
| 19:00:23 | sean-k-mooney | that was suggested just to minimise the number of places we have to check | |
| 19:01:06 | melwitt | yeah. using the same key becomes a problem if the user never used an image with that key in it and we have set it internally for other reasons | |
| 19:01:12 | sean-k-mooney | are you thinking we woudl add a new instance system metadata key ? | |
| 19:01:31 | sean-k-mooney | or were you leanign to only allowing resize if its not a confilct | |
| 19:01:51 | sean-k-mooney | meaning we shoudl not set it on update but treat it not being set as the old user policy | |
| 19:01:56 | melwitt | if we want to be able to convert via resize, yes. like convert from host => deployment, etc. unless someone has a different idea | |
| 19:01:58 | sean-k-mooney | i.e. defaulting in code instead of in the db | |
| 19:02:45 | sean-k-mooney | if we dont use a new key then the simplest thing to do is treat key not in data as the USER policy | |
| 19:02:50 | melwitt | because if we set image_hw_tpm_secret_security NOT from an image, it will get locked into the instance as if it had the image property, and it will reject any flavor hw:tpm_secret_security that does not agree with it | |
| 19:03:25 | sean-k-mooney | then the key will only be set if it actully comes form the image | |
| 19:03:32 | melwitt | everything currently works fine for legacy => host and legacy => deployment | |
| 19:03:51 | melwitt | the problem comes when you have user => host, user => deployment, host => deployment, etc. new instances basically | |
| 19:04:07 | sean-k-mooney | ya | |
| 19:04:26 | melwitt | but yeah I see what you are saying | |
| 19:04:45 | melwitt | that would work also | |
| 19:05:10 | sean-k-mooney | basicly image_metadata.get("image_hw_tpm_secret_security", "user") in virt.hardware.get_tpm_secret_security_constraint() | |
| 19:05:48 | sean-k-mooney | well | |
| 19:05:54 | sean-k-mooney | hum | |
| 19:05:57 | sean-k-mooney | htat does not quite work | |
| 19:06:12 | sean-k-mooney | in the resize case we still need to know if its set or not set | |
| 19:06:21 | sean-k-mooney | but for most other case it wil work | |
| 19:08:06 | sean-k-mooney | i think you can still do it pretty cleanly | |
| 19:08:16 | sean-k-mooney | but i dont know are we giving up anything else by doing it that way | |
| 19:08:44 | melwitt | yeah. it's hard to know ahead of time | |
| 19:09:18 | melwitt | what I'm doing now is writing up some more func tests and tempest tests to sort of demonstrate where the series is at the moment with regard to resize and rebuild behaviors | |
| 19:10:10 | melwitt | I was thinking looking at those would make it easier to reason about how it's working at the moment and help us decide what to do next. at least it helps for me | |
| 19:30:34 | sean-k-mooney | ya that sound like a good approch | |
| 19:33:22 | sean-k-mooney | hum so this is the curretn defintion https://review.opendev.org/c/openstack/nova/+/942502/17/nova/virt/hardware.py | |
| 19:33:49 | sean-k-mooney | and like the ohter get_*_constraint | |
| 19:34:20 | sean-k-mooney | functions it only thake the flavor/image and does not know if it is a resize ectra | |
| 19:34:41 | sean-k-mooney | so if we leave it as it it will work the way we want | |
| 19:35:01 | sean-k-mooney | but it means we will need to do the defaulting diffently | |
| 19:35:15 | sean-k-mooney | which isnot great | |
| 19:35:51 | sean-k-mooney | melwitt: there is another option actully | |
| 19:36:08 | sean-k-mooney | melwitt: instead of defaulting the value to "user" for the exiting vms | |
| 19:36:18 | sean-k-mooney | we could defautl it to "legacy" | |
| 19:36:40 | sean-k-mooney | which for all intents woudl be the same as user excpt it allows you to cange to a diffent policy | |
| 19:37:05 | sean-k-mooney | in other words we would asdd a new value to the enum just for upgrades | |
| 19:37:32 | sean-k-mooney | im not sure if that is a good idea or not but its an option to consider i guess | |
| 19:45:07 | melwitt | sean-k-mooney: hm yeah I hadn't considered that | |
| 19:45:55 | sean-k-mooney | we did somethign similar for pci neuma affinity. we added a "legacy" value for the old default when we added new policies | |
| 19:46:04 | sean-k-mooney | we intened to eventually change the default but that never happened | |
| 19:46:31 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#pci.alias | |
| 19:46:34 | melwitt | ah, good to know | |
| 19:46:41 | sean-k-mooney | numa_policy | |
| 19:46:43 | sean-k-mooney | Required NUMA affinity of device. Valid values are: legacy, preferred, required, and socket. | |
| 19:47:06 | sean-k-mooney | i belive we intened to make preferred the default but we never got around to it | |
| 19:47:59 | melwitt | haha | |
| 19:48:41 | sean-k-mooney | ok im wrapping for today, enjoy your evening | |
| 19:50:12 | melwitt | ttyl o/ | |
| #openstack-nova - 2025-10-01 | |||
| 02:41:18 | opendevreview | melanie witt proposed openstack/nova master: Add hw_tpm_secret_security image property https://review.opendev.org/c/openstack/nova/+/940196 | |
| 02:41:18 | opendevreview | melanie witt proposed openstack/nova master: Move cleanup of vTPM secret from driver to compute https://review.opendev.org/c/openstack/nova/+/962007 | |
| 02:41:19 | opendevreview | melanie witt proposed openstack/nova master: TPM: support instances with `user` secret security https://review.opendev.org/c/openstack/nova/+/942502 | |
| 02:41:19 | opendevreview | melanie witt proposed openstack/nova master: Add hw:tpm_secret_security extra spec validation https://review.opendev.org/c/openstack/nova/+/940197 | |
| 02:41:20 | opendevreview | melanie witt proposed openstack/nova master: Add vtpm_secret_(uuid|value) to LibvirtLiveMigrateData https://review.opendev.org/c/openstack/nova/+/952628 | |
| 02:41:20 | opendevreview | melanie witt proposed openstack/nova master: TPM: support instances with `host` secret security https://review.opendev.org/c/openstack/nova/+/941795 | |
| 02:41:21 | opendevreview | melanie witt proposed openstack/nova master: TPM: bump service version and require it for live migration https://review.opendev.org/c/openstack/nova/+/962051 | |
| 02:41:21 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `host` secret security https://review.opendev.org/c/openstack/nova/+/941483 | |
| 02:41:23 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| 02:41:23 | opendevreview | melanie witt proposed openstack/nova master: TPM: support instances with `deployment` secret security https://review.opendev.org/c/openstack/nova/+/942021 | |
| 02:41:25 | opendevreview | melanie witt proposed openstack/nova master: TPM: add late check for supported TPM secret security https://review.opendev.org/c/openstack/nova/+/956975 | |
| 02:41:25 | opendevreview | melanie witt proposed openstack/nova master: TPM: test live migration between hosts with different security https://review.opendev.org/c/openstack/nova/+/952629 | |
| 02:41:27 | opendevreview | melanie witt proposed openstack/nova master: Opt-in to new TPM secret security via resize https://review.opendev.org/c/openstack/nova/+/962052 | |
| 02:45:34 | opendevreview | melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477 | |
| 06:13:49 | opendevreview | Jonas Schäfer proposed openstack/nova master: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/955657 | |
| 09:42:26 | sean-k-mooney | gibi: fun https://review.opendev.org/c/openstack/placement/+/962596 | |
| 09:43:10 | sean-k-mooney | the inital fix was more of a stop the bleeding type fix rather then a full rewrite some im not surpised that it did nto cover all edgecases | |
| 09:44:32 | sean-k-mooney | ValueError: Length too long: 11601115 so your functional test are failign because we are hitting the max subunite packet lenth in the test outpu | |
| 09:45:00 | sean-k-mooney | i tought this was fixed in stestr a long time ago but maybe we worked aroudn that in nova or didnt apply the fix to placemnt | |
| 10:05:29 | gibi | sean-k-mooney: "fun" indeed. what I learned is that our first fix limited the search space of the valid candidates with a global limit, but it does not limit the search space of the intermediate representaton placement uses, and that represenatation is even bigger causing the issue. | |
| 10:06:00 | sean-k-mooney | right i think that was at least partly expected | |
| 10:06:50 | sean-k-mooney | we dicussed that we woudl need to refactor the algorithim to do a breath first lazy pick form each host up to the relevent limits | |
| 10:06:55 | sean-k-mooney | if we wanted to properly fix it | |
| 10:07:15 | sean-k-mooney | you added the breathfirst bit | |
| 10:07:28 | sean-k-mooney | but i dont think you made it lazy in the orginal change did you? | |
| 10:08:04 | sean-k-mooney | i guess we also only counted valid reulst toward the limits | |
| 10:08:06 | gibi | lazyness is not the problem afaik. we are generators all the way down | |
| 10:08:18 | gibi | and we stop when enough valid candidates are generated | |
| 10:08:23 | sean-k-mooney | so there is also the consideration of just how many candiates we examin | |
| 10:08:30 | gibi | but to generate enough valid candidate we go throuhg a lot of invalid one | |
| 10:08:38 | sean-k-mooney | ya | |
| 10:08:53 | sean-k-mooney | so really we need a second config option for how many we woudl evaculate | |
| 10:09:43 | gibi | that is hard, as in the current config 300k invalid is generated before the first valid is found from the 40k valid and 16M total candidates | |
| 10:09:46 | sean-k-mooney | i.e limit=100 , check=10000 | |
| 10:10:06 | sean-k-mooney | ya | |
| 10:10:40 | sean-k-mooney | really we need a better approch overall to this problem rather then trying to retofit the existign algorthim | |
| 10:10:54 | sean-k-mooney | but obviouly that is a much larger change | |
| 10:10:57 | gibi | I have high level ideas how to prune the search when we found an invalid candidate | |
| 10:11:21 | sean-k-mooney | i was just going to ask | |
| 10:11:27 | gibi | I just need time to put it together and see if it is enough help or not | |