Describe the feature
The cloud-init client will inject info into the metadata from the host
Something like:
"v1": {
"_beta_keys": [
"subplatform"
],
"distro": "sles",
"distro_release": "x86_64",
"distro_version": "15.5",
"instance-id": "i-9c239758",
"instance_id": "i-9c239758",
"machine": "x86_64",
"platform": "nocloud",
"public_ssh_keys": [],
"python_version": "3.6.15",
"variant": "suse"
}
if I have a template like:
## template: jinja
#cloud-config
{% if v1.variant == 'suse' %}
{% set def_dir = '/foo' %}
{% else %}
{% set def_dir = '/bar' %}
{% endif %}
write_files:
- content: |
my stuff
path: {{ def_dir }}/myfile
permissions: '0644'
owner: 'root:root'
The v1.variant is not stored in the metadata-service and so the render from the ochami CLI will never work.
I would like the ability to inject this kind of data on the CLI to get rendering to work, something like
ochami cloud-init group render --extra-vars='"v1.variant":"suse"' <template> <node>
Why do you want this feature?
This would help render templates where the variables are instantiated on boot and not a part of the metadata-service.
Alternatives you've considered
No response
Additional context
No response
Code of Conduct
Describe the feature
The cloud-init client will inject info into the metadata from the host
Something like:
if I have a template like:
The
v1.variantis not stored in the metadata-service and so the render from the ochami CLI will never work.I would like the ability to inject this kind of data on the CLI to get rendering to work, something like
Why do you want this feature?
This would help render templates where the variables are instantiated on boot and not a part of the metadata-service.
Alternatives you've considered
No response
Additional context
No response
Code of Conduct