On 19/04/2021 22:44, Manish Mahalwal wrote:
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 https://github.com/canonical/cloud-init/pull/777 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)?
I am asking this because https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/ve... https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/vendordata-reboot.html mentions that you can multiple REST services to fetch multiple dynamic vendordata's. So, if we set the 'name' attribute to 'cloud-init' then how are we going to differentiate between different REST services, since Nova expects that the key should be unique and repeat key would be ignored (from the specs). For example:
vendordata_dynamic_targets=name1@http://example.com,name2@http://example2.com http://example.com,name2@http//example2.com
{ "name1": { "cloud-init": "#cloud-config\n..." }, "name2": { "cloud-init": "#cloud-config\n..." } }So, essentially, which among the two options is correct?
- 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
- 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!
well dynmaic vendor data is not primary for cloud-init it can be consumed by cloud init but it was created to provide info for agents that rackspace developed themselves unfortunetlly this is one of the more obscure feature that is very very rarely used. it has not been updated more or less since it was added and most of the people that were involved nolonger work on nova.
i think 2 is what they were expecting to work but im not sure really. i dont think either is nessisarly invlalid from a nova point of view the question here really is what does cloud-init actully require.
/ / /Manish Mahalwal/ /MathWorks/
On Fri, 16 Apr 2021 at 20:00, Sean Mooney <smooney@redhat.com mailto:smooney@redhat.com> wrote:
On 15/04/2021 15:53, Manish Mahalwal wrote: > Hi All, > > I am working with OpenStack Pike and cloud-init 21.1. I am able to > successfully pass dynamic vendor data to the config drive of an > instance. However, cloud-init 21.1 just reads all the 'x' bytes of the > vendor_data2.json but it doesn't execute the contents of the json. > Although, static vendor data works perfectly fine and the YAML file in > the JSON is executed as expected by cloud-init 21.1 > > * Now, the person who wrote the code for handling dynamic vendordata > in cloud-init (https://github.com/canonical/cloud-init/pull/777 <https://github.com/canonical/cloud-init/pull/777> > <https://github.com/canonical/cloud-init/pull/777 <https://github.com/canonical/cloud-init/pull/777>>) says that the JSON > cloud-init expects is of the form: > > {"cloud-init": "#cloud-config\npackage_upgrade: True\npackages:\n > - black\nfqdn: cloud-overridden-by-vendordata2.example.org <http://cloud-overridden-by-vendordata2.example.org>."} > > the reference implementation for the dynamic vendor data backend was https://github.com/mikalstill/vendordata <https://github.com/mikalstill/vendordata> and it was a feature developed specificaly for rackspace. the data format that service should return is # { # "hostname": "foo", # "image-id": "75a74383-f276-4774-8074-8c4e3ff2ca64", # "instance-id": "2ae914e9-f5ab-44ce-b2a2-dcf8373d899d", # "metadata": {}, # "project-id": "039d104b7a5c4631b4ba6524d0b9e981", # "user-data": null # } # An example of this data: https://github.com/mikalstill/vendordata/blob/master/app.py#L34-L42 <https://github.com/mikalstill/vendordata/blob/master/app.py#L34-L42> this blog post explains how it should work https://www.madebymikal.com/nova-vendordata-deployment-an-excessively-detailed-guide/ <https://www.madebymikal.com/nova-vendordata-deployment-an-excessively-detailed-guide/> > * I believe that the JSON should have another outer key (as mentioned > here > https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/vendordata-reboot.html <https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/vendordata-reboot.html> > <https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/vendordata-reboot.html <https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/vendordata-reboot.html>>) > which is the name of the microservice specified in nova.conf file and > that the inner key should be cloud-init. > > In nova.conf: > vendordata_dynamic_targets=name1@http://example.com <http://example.com>,name2@http://example2.com <http://example2.com> > <http://example.com <http://example.com>,name2@http//example2.com <http://example2.com>> > > { > "name1": { > "cloud-init": "#cloud-config\n..." > }, > "name2": { > "cloud-init": "#cloud-config\n..." > } > } > > > > > >>Who is right and who is wrong? > > To read more on this please go through the following: > https://bugs.launchpad.net/cloud-init/+bug/1841104 <https://bugs.launchpad.net/cloud-init/+bug/1841104> > <https://bugs.launchpad.net/cloud-init/+bug/1841104 <https://bugs.launchpad.net/cloud-init/+bug/1841104>> >