| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-01-27 | |||
| 17:11:54 | sean-k-mooney | rm_work[m]: https://www.madebymikal.com/nova-vendordata-deployment-an-excessively-detailed-guide/ | |
| 17:12:09 | rm_work[m] | hmm | |
| 17:12:26 | rm_work[m] | yeah that was the guide I was originally following | |
| 17:13:26 | sean-k-mooney | yep so the responce format should be the same as the static json file | |
| 17:13:29 | rm_work[m] | ok I'll try again again again | |
| 17:13:56 | sean-k-mooney | the hack of using a single string with the file contents for cloud init config is abusign the fact that a string is a valid json document | |
| 17:14:45 | sean-k-mooney | we expect the respocne to be a valid json documetn and specifcly a json object but as long as its valid json it can be proceesed by nova | |
| 17:21:07 | rm_work[m] | ok, i'm trying again | |
| 17:22:14 | rm_work[m] | I feel like I was dealing with like 4 different issues at the same time, and by the time I solved them all I was in this weird configuration and had made some inaccurate assumptions about what the actual issues were | |
| 17:32:24 | rm_work[m] | yeah ok, that does seem to work T_T | |
| 17:32:42 | rm_work[m] | so it looks like almost everything I had to adjust to get this to work was likely unnecessary | |
| 17:33:14 | rm_work[m] | I BELIEVE there is still an issue with return codes -- nova will not actually include the body of the response if the return code is a 5XX right? | |
| 17:33:52 | sean-k-mooney | proably | |
| 17:34:06 | sean-k-mooney | but your server should be returnning a 200 ok for the get request we do | |
| 17:35:15 | rm_work[m] | yeah there are cases where the request result is an error, but we do want that returned to the user, so I'm just blindly doing 200 OK returns and just including an error in the body. that does make some sense at least, the CALL didn't fail, just the internal operation did. | |
| 17:36:18 | sean-k-mooney | ya so if you want to return an errror in the body it needs to be a json body not html or it will break nova | |
| 17:36:41 | sean-k-mooney | nova will likly just drop it but its expcting json | |
| 17:36:52 | sean-k-mooney | you could jsut have a single string as i noted above | |
| 17:36:55 | rm_work[m] | yeah I made a structure like '{"success": False, "error": "blah"}' | |
| 17:37:03 | sean-k-mooney | ack | |
| 17:37:06 | sean-k-mooney | that shoudl work | |
| 17:39:32 | rm_work[m] | yeah ok thanks for calling that stuff out, this simplifies things a bit | |
| 19:26:25 | rm_work[m] | sean-k-mooney: ah ok so I see now, I'm relying on it going into /var/lib/cloud/instance/vendor-data2.txt on boot | |
| 19:27:07 | rm_work[m] | when I test just hitting the endpoint, yes it does return properly... but if I boot a new VM, nothing shows up there with this setup | |
| 19:27:22 | rm_work[m] | going back through to test individually to see whether the issue is the naming or the JSON-encoding | |
| 19:27:38 | rm_work[m] | I think maybe this is why I had to name it cloud-init | |
| 19:29:13 | opendevreview | Ghanshyam proposed openstack/nova master: PoC: Graceful shutodwn of nova services https://review.opendev.org/c/openstack/nova/+/967261 | |
| 19:29:55 | opendevreview | Ghanshyam proposed openstack/nova master: PoC: Graceful shutodwn of nova services https://review.opendev.org/c/openstack/nova/+/967261 | |
| 19:45:42 | rm_work[m] | so I guess this is more an issue of how cloud-init is configured to call/parse the vendordata endpoint | |
| 19:48:23 | sean-k-mooney | rm_work[m]: to have that work you need config drive enabled | |
| 19:48:30 | sean-k-mooney | it will be placed in the iso | |
| 19:48:39 | sean-k-mooney | and then it shoudl get mounted with the other info there | |
| 19:48:52 | sean-k-mooney | but in that case it will only be updated once on first boot | |
| 19:49:16 | sean-k-mooney | so if it failed when the config drive was irst build and you fixed it after it would not be present | |
| 20:08:06 | rm_work[m] | yeah, so what I'm seeing is that IF I name it cloud-init AND I return a single "string" from a json.dumps(), then /var/lib/cloud/instance/vendor-data2.txt does contain the actual JSON | |
| 20:10:19 | rm_work[m] | which implies that cloud-init hits that endpoint, pulls out the cloud-init key, and json-decodes it O_o | |
| 20:10:46 | sean-k-mooney | yes it does | |
| 20:11:01 | sean-k-mooney | it will use it as one of the input like user-data | |
| 20:11:33 | sean-k-mooney | so it a way for you as a cloud amdin for example to auto install teh qemu-guest-agent or do similar customaistion | |
| 20:11:58 | sean-k-mooney | now a lot of poeple dont what the cloud servidce provider doing that but the functionatliy exits in cloud-init for it | |
| 20:12:42 | sean-k-mooney | if the content of the string is a cloud-cofnig compatiabel file for example you can use the normal cloud init moduels | |
| 20:12:59 | sean-k-mooney | https://cloudinit.readthedocs.io/en/latest/explanation/about-cloud-config.html#example-cloud-config-file | |
| 20:13:40 | sean-k-mooney | cloudinit.readthedocs.io/en/latest/explanation/vendordata.html | |
| 20:13:51 | sean-k-mooney | Vendor-data follows the same rules as user-data, with the following caveats: | |
| 20:13:53 | sean-k-mooney | Users have ultimate control over vendor-data. They can disable its execution or disable handling of specific parts of multi-part input. | |
| 20:13:55 | sean-k-mooney | By default it only runs on first boot. | |
| 20:13:57 | sean-k-mooney | Vendor-data can be disabled by the user. If the use of vendor-data is required for the instance to run, then vendor-data should not be used. | |
| 20:13:59 | sean-k-mooney | User-supplied cloud-config is merged over cloud-config from vendor-data. | |
| 20:14:53 | sean-k-mooney | rm_work[m]: while its techinally docuematned bhavior of could-init its not someithgn that operator and user geneerally expect | |
| 20:42:16 | opendevreview | Merged openstack/nova master: [hacking]Do not mock threading.Event https://review.opendev.org/c/openstack/nova/+/971454 | |
| #openstack-nova - 2026-01-28 | |||
| 01:43:49 | opendevreview | Merged openstack/nova master: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/955657 | |
| 08:18:09 | opendevreview | Merged openstack/nova master: Use the correct name for the ironic check job https://review.opendev.org/c/openstack/nova/+/974781 | |
| 10:07:57 | amorin | hello team, I'd like to know if john or someone else already worked on the following spec? https://blueprints.launchpad.net/nova/+spec/pci-passthrough-groups | |
| 10:08:15 | amorin | I am asking because we would be interested in joining the force to work on it if not | |
| 10:14:29 | r-taketn | gibi: bauzas: Hello. Could you please take another look at the SEV refactoring patches(https://review.opendev.org/q/topic:%22bp/generalize-sev-code%22) when you have a moment? I have updated the code and comments based on your previous feedbacks. | |
| 10:14:42 | bauzas | definetly, that's on my TODOlist | |
| 10:15:02 | r-taketn | bauzas: Thank you | |
| 10:54:31 | opendevreview | John Garbutt proposed openstack/nova master: Fix ironic instance rebuild with API >=2.93 https://review.opendev.org/c/openstack/nova/+/963298 | |
| 10:56:35 | opendevreview | John Garbutt proposed openstack/nova master: Fix ironic instance rebuild with API >=2.93 https://review.opendev.org/c/openstack/nova/+/963298 | |
| 11:44:15 | lajoskatona | Uggla: Hi, I have a patch series for migrating neutronclient calls in nova to SDK: https://review.opendev.org/q/topic:%22sdk_for_neutron%22 | |
| 11:45:27 | lajoskatona | Uggla: this week I rebased most of them, and 1st 4 (calls for Networks, Subnets, Extension, FIPs) are now green and without merge conflict | |
| 11:46:29 | lajoskatona | Uggla: I don't know if the team has free timeslots to review such patches :-) (Wink-wink.... :P) | |
| 11:48:23 | lajoskatona | I left few todos to remove or finalize when all the calls are migrated to SDK, but any idea can be useful what should be a future proof solution for such a slow effort which can affect legacy things in Nova | |
| 12:45:06 | opendevreview | huanhongda proposed openstack/nova master: Live migration with iothreads https://review.opendev.org/c/openstack/nova/+/975000 | |
| 14:09:26 | opendevreview | Johannes Beisiegel proposed openstack/nova master: Put nova-compute detach behind a different lock than attach https://review.opendev.org/c/openstack/nova/+/975011 | |
| 14:15:33 | opendevreview | Johannes Beisiegel proposed openstack/nova master: Put nova-compute detach behind a different lock than attach https://review.opendev.org/c/openstack/nova/+/975011 | |
| 14:40:54 | jkulik | dansmith: if you can find some time, please take a look at https://review.opendev.org/c/openstack/nova/+/971068 - your input on the question there would be much appreciated. context: fully-aync volume-attachment API call | |
| 14:41:26 | dansmith | jkulik: I know, I saw the oing from gibi, I just haven't gotten to it in my stack.. I'll try to do it today | |
| 14:41:31 | dansmith | s/oing/ping/ | |
| 14:41:55 | jkulik | thank you. didn't want to bother you too much, just in case you oversaw :) | |
| 15:06:57 | sean-k-mooney | amorin: so no but i did a poc of it recently | |
| 15:07:35 | sean-k-mooney | amorin: https://review.opendev.org/c/openstack/nova/+/973604 i was condierting proposting it again for the 2026.2 cycle | |
| 15:10:50 | amorin | oh nice! | |
| 15:11:35 | sean-k-mooney | i have a draft update spec that i was going to push this week with some of the details form the poc | |
| 15:15:01 | sean-k-mooney | amorin: i have not done a lot of testing curently but i got it to the point of booting a vm with a pci group | |
| 15:15:14 | sean-k-mooney | if you have time to test it and give feeback please do | |
| 15:16:12 | amorin | yup, will try to test this here, I have a lab that could maybe be used for this | |
| 15:16:18 | amorin | thanks for the heads up | |
| 15:34:04 | gibi | upstream eventlet meeting https://meet.google.com/bcy-uqoz-hje | |
| 16:35:30 | Uggla | lajoskatona I have seen your request above. I will ask during next upstream meeting. In the meantime I will try to review them. I know a little about it because I did it for manila. | |
| 16:37:07 | lajoskatona | Uggla: thanks, I can join the meeting (next Monday?) | |
| 16:38:05 | Uggla | lajoskatona if you wish yes. Monday 16:00 UTC. | |
| 16:39:27 | lajoskatona | Uggla: thanks | |
| 17:11:09 | opendevreview | Lajos Katona proposed openstack/nova master: Use SDK for Neutron Ports https://review.opendev.org/c/openstack/nova/+/969298 | |
| 17:17:38 | stephenfin | gmaan: jfyi, we're only missing your review on the patches for the servers and server shares APIs to close out the openapi series. It would be great if you could get to it at some point in the near future | |
| 17:40:02 | gmaan | stephenfin: yeah, its in my list. I will check those sometime early next week | |
| 22:55:12 | opendevreview | melanie witt proposed openstack/nova master: Add vtpm_secret_(uuid|value) to LibvirtLiveMigrateData https://review.opendev.org/c/openstack/nova/+/952628 | |
| 22:55:13 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `host` secret security https://review.opendev.org/c/openstack/nova/+/941483 | |
| 22:55:13 | opendevreview | melanie witt proposed openstack/nova master: TPM: prepare to bump service version for live migration https://review.opendev.org/c/openstack/nova/+/962051 | |
| 22:55:14 | opendevreview | melanie witt proposed openstack/nova master: TPM: test live migration between hosts with different security https://review.opendev.org/c/openstack/nova/+/952629 | |
| 22:55:14 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| 22:55:15 | opendevreview | melanie witt proposed openstack/nova master: TPM: opt-in to new TPM secret security via resize https://review.opendev.org/c/openstack/nova/+/962052 | |
| 22:55:15 | opendevreview | melanie witt proposed openstack/nova master: TPM: add late check for supported TPM secret security https://review.opendev.org/c/openstack/nova/+/956975 | |
| 22:55:16 | opendevreview | melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477 | |
| #openstack-nova - 2026-01-29 | |||
| 00:44:04 | opendevreview | melanie witt proposed openstack/nova master: unified limits: Fix openstacksdk usage for endpoint discovery https://review.opendev.org/c/openstack/nova/+/975106 | |
| 00:48:23 | opendevreview | melanie witt proposed openstack/nova master: unified limits: Fix openstacksdk usage for endpoint discovery https://review.opendev.org/c/openstack/nova/+/975106 | |
| 01:27:37 | opendevreview | melanie witt proposed openstack/nova master: unified limits: Fix openstacksdk usage for endpoint discovery https://review.opendev.org/c/openstack/nova/+/975106 | |
| 07:23:30 | opendevreview | huanhongda proposed openstack/nova master: Live migration with iothreads https://review.opendev.org/c/openstack/nova/+/975000 | |
| 07:27:03 | opendevreview | huanhongda proposed openstack/nova master: Live migration with iothreads https://review.opendev.org/c/openstack/nova/+/975000 | |
| 08:07:25 | opendevreview | huanhongda proposed openstack/nova master: numa: Respect allocation ratios for non-pinned NUMA instances https://review.opendev.org/c/openstack/nova/+/971409 | |