| 2020-03-04 03:58:06 |
Chad Smith |
bug |
|
|
added bug |
| 2020-03-04 04:02:31 |
Chad Smith |
description |
Cloud-init allows user-data to provide a "## template: jinja" header line in user-data in order to render custom cloud-config based on any instance metadata found in /run/cloud-init/instance-data.json.
There are a number of use cases where it would be beneficial to provide unique cloud-config user-data based on what ubuntu release, machine architecture kernel or merged_config default_user you an image may have configured.
Allow cloud customers to write a single cloud-config jinja template which can customize configuration options based on what it's operating environment ends up being.
Add 2 top-level keys to the persisted instance-data.json file:
merged_cfg: the merged cloud-config from /etc/cloud/cloud.cfg and /etc/cloud/cloud.cfg.d/*cfg
This merged_cfg is helpful in debug and triage of cloud-init bugs as the filesystem
images frequently override Ubuntu certified cloud-image defaults.
sys_info: system platform and distro information surfaced by uname or python.platform.
This data is already obtained by cloudinit.util.system_info() which is used by
cloud-init runtime to determine cloud-init behavior on every Ubuntu series and all
supported distributions.
For ease of use in templates, some of the sys_info fields are generalized as top-level 'v1' standard keys. The following are the new generalized v1 instance data keys:
distro, distro_release, distro_version, variant
kernel_release, system_platform, machine, and python_version
This allows a single #cloud-config user-data which would allow for custom cloud-config based on distro details:
## template: jinja
#cloud-config
runcmd:
{% if distro_version == 'xenial' %}
- echo add custom networking extensions to /etc/network/interfaces.d/
{% elif distro_version == 'bionic' %}
- echo add my custom networking extensions to /etc/netplan/
{% elif distro == 'centos' %}
- echo do something fun with /etc/sysconfig
{% endif %} |
Cloud-init allows user-data to provide a "## template: jinja" header line in user-data in order to render custom cloud-config based on any instance metadata found in /run/cloud-init/instance-data.json.
There are a number of use cases where it would be beneficial to provide unique cloud-config user-data based on what ubuntu release, machine architecture kernel or merged_config default_user you an image may have configured.
Allow cloud customers to write a single cloud-config jinja template which can customize configuration options based on what it's operating environment ends up being.
Add 2 top-level keys to the persisted instance-data.json file:
merged_cfg:
* The merged cloud-config from /etc/cloud/cloud.cfg and
/etc/cloud/cloud.cfg.d/*cfg
* This merged_cfg is helpful in debug and triage of cloud-init bug
as custom images frequently override Ubuntu certified
cloud-image defaults.
sys_info: system platform, arch, kernel and distro info
* This data is already obtained by cloudinit.util.system_info which
is used at runtime to determine behavior on every Ubuntu series
and any other supported distributions.
For ease of use in templates, some of the sys_info fields are generalized as top-level 'v1' standard keys.
The following are the new generalized v1 instance data keys:
distro, distro_release, distro_version, variant
kernel_release, system_platform, machine, and python_version
This allows a single #cloud-config user-data which would allow for custom cloud-config based on distro details:
## template: jinja
#cloud-config
runcmd:
{% if distro_version == 'xenial' %}
- echo add custom networking extensions to /etc/network/interfaces.d/
{% elif distro_version == 'bionic' %}
- echo add my custom networking extensions to /etc/netplan/
{% elif distro == 'centos' %}
- echo do something fun with /etc/sysconfig
{% endif %} |
|
| 2020-03-04 04:02:51 |
Chad Smith |
description |
Cloud-init allows user-data to provide a "## template: jinja" header line in user-data in order to render custom cloud-config based on any instance metadata found in /run/cloud-init/instance-data.json.
There are a number of use cases where it would be beneficial to provide unique cloud-config user-data based on what ubuntu release, machine architecture kernel or merged_config default_user you an image may have configured.
Allow cloud customers to write a single cloud-config jinja template which can customize configuration options based on what it's operating environment ends up being.
Add 2 top-level keys to the persisted instance-data.json file:
merged_cfg:
* The merged cloud-config from /etc/cloud/cloud.cfg and
/etc/cloud/cloud.cfg.d/*cfg
* This merged_cfg is helpful in debug and triage of cloud-init bug
as custom images frequently override Ubuntu certified
cloud-image defaults.
sys_info: system platform, arch, kernel and distro info
* This data is already obtained by cloudinit.util.system_info which
is used at runtime to determine behavior on every Ubuntu series
and any other supported distributions.
For ease of use in templates, some of the sys_info fields are generalized as top-level 'v1' standard keys.
The following are the new generalized v1 instance data keys:
distro, distro_release, distro_version, variant
kernel_release, system_platform, machine, and python_version
This allows a single #cloud-config user-data which would allow for custom cloud-config based on distro details:
## template: jinja
#cloud-config
runcmd:
{% if distro_version == 'xenial' %}
- echo add custom networking extensions to /etc/network/interfaces.d/
{% elif distro_version == 'bionic' %}
- echo add my custom networking extensions to /etc/netplan/
{% elif distro == 'centos' %}
- echo do something fun with /etc/sysconfig
{% endif %} |
Cloud-init allows user-data to provide a "## template: jinja" header line in user-data in order to render custom cloud-config based on any instance metadata found in /run/cloud-init/instance-data.json.
There are a number of use cases where it would be beneficial to provide unique cloud-config user-data based on what ubuntu release, machine architecture kernel or merged_config default_user you an image may have configured.
Allow cloud customers to write a single cloud-config jinja template which can customize configuration options based on what it's operating environment ends up being.
Add 2 top-level keys to the persisted instance-data.json file:
merged_cfg:
* The merged cloud-config from /etc/cloud/cloud.cfg and
/etc/cloud/cloud.cfg.d/*cfg
* This merged_cfg is helpful in debug and triage of cloud-init bug
as custom images frequently override Ubuntu certified
cloud-image defaults.
sys_info:
* system platform, arch, kernel and distro info
* This data is already obtained by cloudinit.util.system_info which
is used at runtime to determine behavior on every Ubuntu series
and any other supported distributions.
For ease of use in templates, some of the sys_info fields are generalized as top-level 'v1' standard keys.
The following are the new generalized v1 instance data keys:
distro, distro_release, distro_version, variant
kernel_release, system_platform, machine, and python_version
This allows a single #cloud-config user-data which would allow for custom cloud-config based on distro details:
## template: jinja
#cloud-config
runcmd:
{% if distro_version == 'xenial' %}
- echo add custom networking extensions to /etc/network/interfaces.d/
{% elif distro_version == 'bionic' %}
- echo add my custom networking extensions to /etc/netplan/
{% elif distro == 'centos' %}
- echo do something fun with /etc/sysconfig
{% endif %} |
|
| 2020-03-04 04:05:54 |
Chad Smith |
description |
Cloud-init allows user-data to provide a "## template: jinja" header line in user-data in order to render custom cloud-config based on any instance metadata found in /run/cloud-init/instance-data.json.
There are a number of use cases where it would be beneficial to provide unique cloud-config user-data based on what ubuntu release, machine architecture kernel or merged_config default_user you an image may have configured.
Allow cloud customers to write a single cloud-config jinja template which can customize configuration options based on what it's operating environment ends up being.
Add 2 top-level keys to the persisted instance-data.json file:
merged_cfg:
* The merged cloud-config from /etc/cloud/cloud.cfg and
/etc/cloud/cloud.cfg.d/*cfg
* This merged_cfg is helpful in debug and triage of cloud-init bug
as custom images frequently override Ubuntu certified
cloud-image defaults.
sys_info:
* system platform, arch, kernel and distro info
* This data is already obtained by cloudinit.util.system_info which
is used at runtime to determine behavior on every Ubuntu series
and any other supported distributions.
For ease of use in templates, some of the sys_info fields are generalized as top-level 'v1' standard keys.
The following are the new generalized v1 instance data keys:
distro, distro_release, distro_version, variant
kernel_release, system_platform, machine, and python_version
This allows a single #cloud-config user-data which would allow for custom cloud-config based on distro details:
## template: jinja
#cloud-config
runcmd:
{% if distro_version == 'xenial' %}
- echo add custom networking extensions to /etc/network/interfaces.d/
{% elif distro_version == 'bionic' %}
- echo add my custom networking extensions to /etc/netplan/
{% elif distro == 'centos' %}
- echo do something fun with /etc/sysconfig
{% endif %} |
Cloud-init allows user-data to provide a "## template: jinja" header line in user-data in order to render custom cloud-config based on any instance metadata found in /run/cloud-init/instance-data.json.
There are a number of use cases where it would be beneficial to provide unique cloud-config user-data based on what ubuntu release, machine architecture kernel or merged_config default_user you an image may have configured.
Allow cloud customers to write a single cloud-config jinja template which can customize configuration options based on what it's operating environment ends up being.
Add 2 top-level keys to the persisted instance-data.json file:
merged_cfg:
* The merged cloud-config from /etc/cloud/cloud.cfg and
/etc/cloud/cloud.cfg.d/*cfg
* This merged_cfg is helpful in debug and triage of cloud-init bug
as custom images frequently override Ubuntu certified
cloud-image defaults.
sys_info:
* system platform, arch, kernel and distro info
* This data is already obtained by cloudinit.util.system_info which
is used at runtime to determine behavior on every Ubuntu series
and any other supported distributions.
For ease of use in templates, some of the sys_info fields are generalized as top-level 'v1' standard keys.
The following are the new generalized v1 instance data keys:
distro, distro_release, distro_version, variant
kernel_release, system_platform, machine, and python_version
This allows a single #cloud-config user-data which would allow for custom cloud-config based on distro details:
## template: jinja
#cloud-config
runcmd:
{% if distro_version == 'xenial' %}
- echo add custom networking extensions to /etc/network/interfaces.d/
{% elif distro_version == 'bionic' %}
- echo add my custom networking extensions to /etc/netplan/
{% elif distro == 'centos' %}
- echo do something fun with /etc/sysconfig
{% endif %}
Potential risk:
The 'merged_cfg' is sourced from the filesystem in which custom images could place sensitive information such as passwords or keys. That merged_cfg will need to be considered a sensitive_metadata_key that is redacted from the world-readable /run/cloud-init/instance-data.json file.
The branch proposed will need to address this sensitivity and non-root users will not be able to run `cloud-init query merged_cfg` as that data will need to be redacted. |
|
| 2020-03-04 04:17:03 |
Chad Smith |
bug |
|
|
added subscriber Ubuntu Release Team |
| 2020-03-04 19:37:35 |
Launchpad Janitor |
cloud-init (Ubuntu): status |
New |
Confirmed |
|
| 2020-03-05 11:04:50 |
Michael Hudson-Doyle |
bug |
|
|
added subscriber Michael Hudson-Doyle |
| 2020-03-10 19:14:11 |
Chad Smith |
cloud-init (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2020-03-10 19:16:54 |
Chad Smith |
cloud-init (Ubuntu): assignee |
|
Chad Smith (chad.smith) |
|
