Thank you for the response, Sean. But, I have already successfully implemented and deployed dynamic vendordata to an Openstack instance using these really good tutorials. So, my issue is not with Openstack but with cloud-init. Even though dynamic vendordata was implemented back in Openstack Pike,
cloud-init, however, was not handling dynamic vendordata until very recently and they implemented it in Feb 2021! So, even though people were able to send dynamic vendordata to instances they were not able to execute any of that dynamic vendordata using cloud-init.
However, even this new implementation from cloud-init comes with issues. I am not able to execute any of the YAML files which I pass through dynamic vendordata. Static vendordata executes perfectly fine though!
Now coming to the issue, the vendordata_dynamic_targets flag in the nova.conf follows the syntax:
vendordata_dynamic_targets=name@<URL>
So, what value should 'name' hold here? Should it be the name you give to the REST service or should it be the name of the package that consumes the vendor_data2.json (cloud-init in this case)?
{
"name1": {
"cloud-init": "#cloud-config\n..."
},
"name2": {
"cloud-init": "#cloud-config\n..."
}
}
So, essentially, which among the two options is correct?
1. in nova.conf: vendordata_dynamic_targets=cloud-init@localhost and my REST service responds with the value of "cloud-init" key to create the following vendor_data2.json
{"cloud-init": "#cloud-config\npackage_upgrade: True\npackages:\n - htop"}
or
2. in nova.conf:
vendordata_dynamic_targets=testing@localhost and my REST service responds with the value of "testing" key.
{"testing": {"cloud-init": "#cloud-config\npackage_upgrade: True\npackages:\n - htop"}}
I hope to get more eyes on this issue as it otherwise renders dynamic vendordata useless if cloud-init doesn't handle it properly. Thank you for your time!
Manish Mahalwal
MathWorks