Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-01-27
15:50:56 rm_work[m] this and any name will work?
15:50:56 rm_work[m] hopefully quick q about nova vendordata dynamicJSON... I can't find it in the docs anywhere but it seems like I need to configure the `vendordata_dynamic_targets` option with the target named `cloud-init@<address>` or else cloud-init doesn't actually return anything for it. is that expected? and how can I use multiple targets if they need to be named that way? or did I maybe get confused from some other bug I had when I was testing
15:58:58 sean-k-mooney rm_work[m]: so yes and no
15:59:13 sean-k-mooney rm_work[m]: we have no upstream supoprt for usign it as a data souce for cloud-init
15:59:29 sean-k-mooney they have some documentation that suggest you could use it that way
15:59:37 sean-k-mooney but ti has never been officaly supproted in nova
16:00:08 sean-k-mooney rm_work[m]: https://github.com/canonical/cloud-init/issues/5221
16:01:47 sean-k-mooney rm_work[m]: in https://github.com/canonical/cloud-init/issues/5221#issuecomment-2086560281 i provide a example of how to hack it to work by doing
16:01:51 sean-k-mooney [API]
16:01:53 sean-k-mooney vendordata_dynamic_targets=['cloud-init:string@http://127.0.0.1:123']
16:04:35 sean-k-mooney there was a spec that was not implemtned this https://review.opendev.org/c/openstack/nova-specs/+/917109/6/specs/2024.2/approved/dynamicjson-vendordata-cloud-config.rst https://blueprints.launchpad.net/nova/+spec/dynamicjson-vendordata-cloud-config
16:05:27 sean-k-mooney rm_work[m]: so yes if your dynmaic backend return a single string that is the cloud init info i think it can work but since it not offially supproted if ti does not its not a nova bug
16:06:00 sean-k-mooney its a new feature as this was never intended to work with cloud init automaticly like that
16:36:38 rm_work[m] I mean I don't need it to RUN as part of cloud-init, I just need cloud-init to properly fetch the contents into the vendordata2.json file
16:37:00 rm_work[m] like, VM boots, user checks the json file and it contains stuff
16:37:20 rm_work[m] using a colon is a neat trick though, ok will try that
16:38:07 sean-k-mooney so it will be present in the the config drive and via the metadata api
16:38:33 sean-k-mooney you just wont be abel to execute scrips in the guest vms via vender data automaticly without the hack
16:38:48 sean-k-mooney so if you just want to make the file avaiable you do not need the hack
16:39:23 sean-k-mooney if you want to install packages ectra then you do but as i noted its not offically supproted so just be aware of that
16:59:23 rm_work[m] yeah it looks like I CAN use any name after all, I think I had an encoding bug originally and fixed that at the same time as trying switching to cloud-init as the key, and assumed I needed that name
17:01:05 rm_work[m] nova doesn't like if the target returns anything other than a string with 200 code
17:01:23 rm_work[m] I was trying to return JSON originally... seeing as how it's called DynamicJSON... but nope lol
17:01:43 rm_work[m] THAT seems like a bug to me but i assume there's a reason
17:10:27 sean-k-mooney nova is expectign a json respocne but a single stirng is also a vaild json responce
17:10:42 sean-k-mooney rm_work[m]: we are doing json.loads on the responce
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

Earlier   Later