| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-09-30 | |||
| 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: Move cleanup of vTPM secret from driver to compute https://review.opendev.org/c/openstack/nova/+/962007 | |
| 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: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: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: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: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: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: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: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: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: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: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: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 | |
| 10:11:28 | sean-k-mooney | what is the direction you are thinking of going wiht this | |
| 10:11:33 | sean-k-mooney | ack | |
| 10:11:47 | gibi | E.g. if G1-R1, G2-R1, G3-R2 is invalid due to R1 is overallocated by G1 and G2 then we don't have to check G1-R1, G2-R1, G3-R3 | |
| 10:12:39 | gibi | so a single invalid candidate can remove a bunch of other possible candidate that would fail the same check the same reason | |
| 10:12:50 | sean-k-mooney | you did something similar to the numa node code in nova too if i recall | |
| 10:12:55 | gibi | I did caching there | |
| 10:13:12 | gibi | here I would rather skip generating the candidate | |
| 10:13:20 | gibi | but the idea is similar | |
| 10:13:24 | sean-k-mooney | ya | |
| 10:13:29 | gibi | don't go through the same sub check repatedly | |
| 10:13:51 | sean-k-mooney | ok well since you have a direction i wont suggest any other but if you want to brainstorm or chat about it let me know | |
| 10:16:25 | gibi | I want to go down to this path a bit, then we can re-discuss | |
| 10:16:57 | gibi | also I think there will be a ptg topic about it as well :) | |
| 10:17:07 | gibi | thanks for checking the patch | |
| 10:17:24 | gibi | I will keep the nova team informed about the progress | |
| 10:20:13 | Vii | for informational purposes, working copy/paste novnc https://github.com/Vishwamithra37/galam_nonvc_copypaste/blob/CopyPasteWorking_NoVnc_OpenStack/README.md | |
| 10:25:23 | sean-k-mooney | Vii: it need a addtiona spice clipborad device added to the xml i belive | |
| 10:25:57 | sean-k-mooney | we looked at it breifly before but did you mange to get it workign without nova code changes? | |
| 10:27:01 | sean-k-mooney | upstream novnc supprot copypaset i bleive but not the way we create the vms | |
| 10:27:54 | sean-k-mooney | https://github.com/novnc/noVNC?tab=readme-ov-file#features | |
| 10:28:33 | sean-k-mooney | https://libvirt.org/formatdomain.html#channel | |
| 10:28:49 | sean-k-mooney | we need to add a qemu-vdagent channel | |
| 10:29:02 | sean-k-mooney | o supprot the clipboard functionalty | |
| 10:30:25 | sean-k-mooney | Vii: i looked into this a bit about a year ago but never worked on a poc | |
| 10:30:58 | sean-k-mooney | but form talking ot our virt team internally this functionalyt shoudl work with vnc and novnc if we wire it up properly | |
| 10:31:04 | sean-k-mooney | without the need for spice | |
| 10:31:42 | sean-k-mooney | it seams like you did it a diffent way by modifying the novnc html client applcation instead | |
| 10:34:23 | bauzas | do people here know how the fuck I could check DEBUG logs with something like _wait_for_log() in either a functional test or a regression one ? | |
| 10:34:32 | sean-k-mooney | this has been requested in teh past so we proably shoudl implement copy paste supprot at some point although VDI usecase for openstack in the past have mainly invovled isntalling a vdi service like window RDP server in the gust in the past | |
| 10:34:56 | bauzas | unless of course if you use OS_DEBUG | |
| 10:35:04 | sean-k-mooney | bauzas: i dont know if we have a wait funciton | |
| 10:35:11 | bauzas | we have one | |
| 10:35:12 | sean-k-mooney | but you can do asserts | |
| 10:35:16 | sean-k-mooney | ack | |
| 10:35:27 | bauzas | even with assertIn, the log doesn't have debug logs | |
| 10:35:49 | sean-k-mooney | it should let me check the capture fixture | |
| 10:36:04 | sean-k-mooney | im pretty sure we hage regression tests that assert debug logs | |
| 10:36:27 | bauzas | I wasn't able to see some of them | |
| 10:37:56 | sean-k-mooney | https://github.com/openstack/nova/blob/b99a882366251f88d145e27312b94692e0b2266f/nova/tests/functional/regressions/test_bug_1853009.py#L109-L111 | |
| 10:38:15 | sean-k-mooney | that may not be a debug log but i expect output to have all logs including debug | |
| 10:39:01 | bauzas | I'm now able to get debug logs by doing in the SetUp : | |