Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cloud-init depends on undefined yaml behavior in LXD implementation #5575

Closed
holmanb opened this issue Aug 1, 2024 · 1 comment · Fixed by #5584
Closed

Cloud-init depends on undefined yaml behavior in LXD implementation #5575

holmanb opened this issue Aug 1, 2024 · 1 comment · Fixed by #5584
Labels
bug Something isn't working correctly

Comments

@holmanb
Copy link
Member

holmanb commented Aug 1, 2024

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:

{'_metadata_api_version': '1.0',
 'config': {'user.meta-data': 'instance-id: test_2'},
 'devices': {'eth0': {'hwaddr': '00:16:3e:e3:ed:2c',
                      'name': 'eth0',
                      'network': 'lxdbr0',
                      'type': 'nic'},
             'root': {'path': '/', 'pool': 'default', 'type': 'disk'}},
 'meta-data': '#cloud-config\n'
              'instance-id: 0b6c31e2-403c-44eb-b610-ad7eafea777e\n'
              'local-hostname: oracular\n'
              'instance-id: test_2'}

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:

  1. 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.

  2. 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.

@holmanb holmanb added bug Something isn't working correctly new An issue that still needs triage labels Aug 1, 2024
@holmanb
Copy link
Member Author

holmanb commented Aug 1, 2024

Filed against LXD as well: canonical/lxd#13853

@holmanb holmanb removed the new An issue that still needs triage label Aug 5, 2024
holmanb added a commit that referenced this issue Aug 5, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working correctly
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant