Merging with data in /etc/cloud/cloud.cfg does not work as expected
Bug #1532234 reported by
Lars Kellogg-Stedman
This bug affects 6 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Expired
|
Low
|
Unassigned |
Bug Description
Given the following user-data:
#cloud-config
merge_how: 'list(append)
disable_root: 0
users:
- name: foobar
gecos: Foo B. Bar
lock-passwd: false
passwd: secret
- name: barfoo
gecos: Bar B. Foo
lock-passwd: true
cloud_
- yum-add-repo
runcmd:
- https:/
The 'users' and 'cloud_
content in /etc/cloud/
expect. This means that it is not possible to augment the
configuration in /etc/cloud/
the entire content of the target key.
Related branches
lp:~oddbloke/cloud-init/merging-doc-clarification
- Patricia Gaughen (community): Approve
- cloud-init Commiters: Pending requested
-
Diff: 128 lines (+27/-21)2 files modifieddoc/merging.rst (+24/-18)
doc/rtd/topics/merging.rst (+3/-3)
Changed in cloud-init: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in cloud-init: | |
assignee: | nobody → Dan Watkins (daniel-thewatkins) |
Changed in cloud-init: | |
assignee: | Dan Watkins (daniel-thewatkins) → nobody |
summary: |
- Merging with data in /etc/cloud/cloud.cfg does not work as expected + Buy Tramadol Online to Overcome Psoriatic Arthritis |
description: | updated |
summary: |
- Buy Tramadol Online to Overcome Psoriatic Arthritis + Merging with data in /etc/cloud/cloud.cfg does not work as expected |
Changed in cloud-init: | |
importance: | High → Low |
To post a comment you must log in.
As I understand it, merging has only ever happened within a particular configuration context (i.e. all parts of user data are merged together, all parts of /etc/cloud/ cloud.cfg{ ,.d/*} are merged together). After that is done, merged user data is used in preference to the merged cloud.cfg.
As such, when adding this functionality, we'll need to be thoughtful about modifying this behaviour. There may be users who are (implicitly) _relying_ on this being the default behaviour. (Consider, for example, someone who is merging user data together to produce a list of users to replace the "ubuntu" user on Ubuntu; this feature could be implemented in a way that would mean that an "ubuntu" user with password-less sudo would start being created on any new instance they launched; this would be a Bad Thing (TM).)