You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The user-defined meta-data key gets appended as a string to the lxd-provided meta-data. This means that duplicate keys can be added, which creates a configuration that isn't well defined. Both 1.1 and 1.2 of the YAML spec state that keys are unique, which this violates.
Cloud-init's implementation uses PyYAML which happens to use the last defined key - and therefore produces the desired outcome (allow user to override the default meta-data), but it depends on undefined behavior. If cloud-init were ever to move to a different YAML library this behavior could break or need to be manually worked around.
In order to preserve the current behavior while creating a path to using standard-compliant yaml while preserving backwards compatibility, we could do the following:
cloud-init could be updated to make values in metadata['config']['user.meta-data'] override values in metadata['meta-data']. This wouldn't change cloud-init's current behavior, which ignores the values in metadata['config']. We could optionally check for a bump to the value in _metadata_api_version before doing this, but this wouldn't be strictly required since this is functionally identical currently.
Once stable distributions have this update, we could update the api to no longer append user meta-data to the default metadata (and bump the meta-data api, if desired). While we're making this change, we might want to drop the #cloud-config comment too. This isn't necessary because meta-data isn't part of cloud-config.
The text was updated successfully, but these errors were encountered:
This was previously unnecessary because:
a. LXD automatically appends the user.meta-data key to default meta-data.
b. In the presence of duplicate keys, PyYAML uses the last key.
This change is the cloud-init part of a set of changes that will enable cloud-init
to avoid depending on undefined behavior. In the future LXD may stop
appending user-defined meta-data to its default meta-data. This change
makes cloud-init forward compatible to LXD for when that change is
implemented.
GH-5575
Bug report
The user-defined meta-data key gets appended as a string to the lxd-provided meta-data. This means that duplicate keys can be added, which creates a configuration that isn't well defined. Both 1.1 and 1.2 of the YAML spec state that keys are unique, which this violates.
The configuration received by cloud-init:
Cloud-init's implementation uses PyYAML which happens to use the last defined key - and therefore produces the desired outcome (allow user to override the default meta-data), but it depends on undefined behavior. If cloud-init were ever to move to a different YAML library this behavior could break or need to be manually worked around.
In order to preserve the current behavior while creating a path to using standard-compliant yaml while preserving backwards compatibility, we could do the following:
cloud-init could be updated to make values in
metadata['config']['user.meta-data']
override values inmetadata['meta-data']
. This wouldn't change cloud-init's current behavior, which ignores the values inmetadata['config']
. We could optionally check for a bump to the value in_metadata_api_version
before doing this, but this wouldn't be strictly required since this is functionally identical currently.Once stable distributions have this update, we could update the api to no longer append user meta-data to the default metadata (and bump the meta-data api, if desired). While we're making this change, we might want to drop the
#cloud-config
comment too. This isn't necessary because meta-data isn't part of cloud-config.The text was updated successfully, but these errors were encountered: