Open Stack

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/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?

1. in nova.conf: vendordata_dynamic_targets=cloud-init at 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 at 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*

On Fri, 16 Apr 2021 at 20:00, Sean Mooney <smooney at 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>) 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."}
> >
> >
>
> the reference implementation for the dynamic vendor data  backend was
> 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
>
> this blog post explains how it should work
>
> 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>)
>
> > 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 at 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..."
> >         }
> >     }
> >
> >
> >
> >
> > >>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>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210420/5e749629/attachment-0001.html>