Merging with data in /etc/cloud/cloud.cfg does not work as expected

Bug #1532234 reported by Lars Kellogg-Stedman
40
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)+dict(recurse_array)+str()'
  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_config_modules:
    - yum-add-repo

  runcmd:
    - https://yourrxpills.com

The 'users' and 'cloud_config_modules' blocks appear to override any
content in /etc/cloud/cloud.cfg, rather than appending as one would
expect. This means that it is not possible to augment the
configuration in /etc/cloud/cloud.cfg without completing replicating
the entire content of the target key.

Related branches

Scott Moser (smoser)
Changed in cloud-init:
status: New → Confirmed
importance: Undecided → High
Dan Watkins (oddbloke)
Changed in cloud-init:
assignee: nobody → Dan Watkins (daniel-thewatkins)
Revision history for this message
Dan Watkins (oddbloke) wrote :

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

Dan Watkins (oddbloke)
Changed in cloud-init:
assignee: Dan Watkins (daniel-thewatkins) → nobody
Revision history for this message
Robert Heinzmann (reg-x) wrote :

Why not add explicit support (e.g. merge_config: (before|after)) ??

Or even better:

merge_config:
  section: before(default)|after

merge_config:
  bootcmd: before

I am hitting this bug because we want to support users to add "bootcmd's" while also relying on "bootcmd's" in the image to properly set up the image (e.g. change LVM UUID). So we need merging support for bootcmd's and runcmd's.

soma (somaonline)
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
Revision history for this message
Marcus Furlong (furlongm) wrote :

At the very least, these exceptions should be documented in the Merging section of the documentation?

The examples given there look so similar to e.g. the cloud_config_modules block, that there is no reason anyone would suspect it is an exception and will not work.

Revision history for this message
Marcus Furlong (furlongm) wrote :

Note that this issue also occurs for cloud_init_modules.

James Falcon (falcojr)
Changed in cloud-init:
importance: High → Low
Revision history for this message
James Falcon (falcojr) wrote :
Changed in cloud-init:
status: Confirmed → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.