Page MenuHomeSoftware Heritage
Create Task
Maniphest T2655

Configure cloud-init to avoid fighting with puppet changes
Closed, MigratedEdits Locked
Actions

Description

Every time virtual machines generated with cloud-init (e.g. the staging hosts) restart, cloud-init will clobber some changes made to them by puppet.

We should configure cloud init to preserve the changes made by puppet, by disabling its intervention on the following:

  • apt sources
  • /etc/hosts (?)
  • /etc/network/interfaces (?)

The relevant config is in /etc/cloud/cloud.cfg (there seems to be a drop-in directory /etc/cloud/cloud.cfg.d that we could use in each profile that touches a "conflicting" file)

Revisions and Commits

rSPSITE puppet-swh-site
D6861rSPSITE3991fc44500b cloud-init: disable the /etc/hosts upgrade on boot

Related Objects

Event Timeline

olasd triaged this task as Normal priority.Oct 1 2020, 2:46 PM
olasd created this task.
vsellier added a subscriber: vsellier.Dec 16 2021, 10:56 PM

it seems cloud init does not support overriding a property defined in the user-data configuration:

from https://cloudinit.readthedocs.io/en/latest/topics/merging.html:

Note, however, that merge algorithms are not used across types of configuration. As was the case before merging was implemented, user-data will overwrite conf.d configuration without merging.

I also tried to override the value from the vendor-data file and provide it through the cicustom value but:
From https://cloudinit.readthedocs.io/en/latest/topics/vendordata.html:

user supplied cloud-config is merged over cloud-config from vendordata.

Also from this same page, one interesting thing to test:

Users providing cloud-config data can use the ‘#cloud-config-jsonp’ method to more finely control their modifications to the vendor supplied cloud-config. For example, if both vendor and user have provided ‘runcmd’ then the default merge handler will cause the user’s runcmd to override the one provided by the vendor.

vsellier changed the task status from Open to Work in Progress.Dec 16 2021, 10:57 PM
vsellier claimed this task.
vsellier added a revision: D6861: cloud-init: disable the /etc/hosts upgrade on boot.Dec 17 2021, 9:29 AM
vsellier added a comment.Dec 17 2021, 2:02 PM

Testing with this config file:

#cloud-config-jsonp
[{ "op": "replace", "path": "/manage_etc_hosts", "value": "False"}]

gives this error:

2021-12-16 22:35:11,471 - __init__.py[DEBUG]: Calling handler CloudConfigPartHandler: [['text/cloud-config', 'text/cloud-config-jsonp']] (text/cloud-config-jsonp, part-001, 3) with frequency always
2021-12-16 22:35:11,472 - cloud_config.py[DEBUG]: Merging by applying json patch [{"op": "replace", "path": "/manage_etc_hosts", "value": "False"}]
2021-12-16 22:35:11,472 - util.py[WARNING]: Failed at merging in cloud config part from part-001
2021-12-16 22:35:11,474 - util.py[DEBUG]: Failed at merging in cloud config part from part-001
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cloudinit/handlers/cloud_config.py", line 138, in handle_part
    self._merge_patch(payload)
  File "/usr/lib/python3/dist-packages/cloudinit/handlers/cloud_config.py", line 113, in _merge_patch
    self.cloud_buf = patch.apply(self.cloud_buf, in_place=False)
  File "/usr/lib/python3/dist-packages/jsonpatch.py", line 312, in apply
    obj = operation.apply(obj)
  File "/usr/lib/python3/dist-packages/jsonpatch.py", line 483, in apply
    raise JsonPatchConflict(msg)
jsonpatch.JsonPatchConflict: can't replace non-existent object 'manage_etc_hosts'
2021-12-16 22:35:11,475 - __init__.py[DEBUG]: Calling handler CloudConfigPartHandler: [['text/cloud-config', 'text/cloud-config-jsonp']] (__end__, None, 3) with frequency always

It seems removing the update_etc_hosts module from the cloud-init-modules is easier. It can be managed by puppet and avoid to change the vm configurations

vsellier added a commit: rSPSITE3991fc44500b: cloud-init: disable the /etc/hosts upgrade on boot.Dec 17 2021, 4:28 PM
vsellier added a comment.EditedDec 17 2021, 4:44 PM

fact installed on the staging nodes:

root@pergamon:/etc/clustershell# clush -b -w @staging 'if [ -e /etc/systemd/system/cloud-init.target.wants/cloud-init.service ]; then echo "cloud-init installed"; echo cloudinit_enabled=true > /etc/facter/facts.d/cloud-init.txt; else echo "cloud-init not installed"; fi'
---------------
counters0.internal.staging.swh.network,deposit.internal.staging.swh.network,objstorage0.internal.staging.swh.network,poc-rancher-sw[0-1].internal.staging.swh.network,poc-rancher.internal.staging.swh.network,rp0.internal.staging.swh.network,scheduler0.internal.staging.swh.network,search0.internal.staging.swh.network,vault.internal.staging.swh.network,webapp.internal.staging.swh.network,worker[0-3].internal.staging.swh.network (15)
---------------
cloud-init installed
---------------
db1.internal.staging.swh.network,storage1.internal.staging.swh.network (2)
---------------
cloud-init not installed

on admin servers:

root@pergamon:/etc/clustershell# clush -b -w @admin 'if [ -e /etc/systemd/system/cloud-init.target.wants/cloud-init.service ]; then echo "cloud-init installed"; echo cloudinit_enabled=true > /etc/facter/facts.d/cloud-init.txt; else echo "cloud-init not installed"; fi'
---------------
bardo.internal.admin.swh.network,rp1.internal.admin.swh.network (2)
---------------
cloud-init installed

and manually added on

  • search1
  • counters1
  • webapp1
  • worker17
  • worker18
vsellier mentioned this in rSPRE58fd7dcbb4f6: terraform: add the cloud-init fact on the server initialization.Dec 17 2021, 4:54 PM
vsellier closed this task as Resolved.Dec 17 2021, 4:54 PM
gitlab-migration changed the task status from Resolved to Migrated.Oct 19 2022, 5:58 PM
gitlab-migration claimed this task.
gitlab-migration added a subscriber: gitlab-migration.

This task has been migrated to GitLab.

About · Developer information · Legal