Public bug reported: (I'm using cloud-init 19.2 under Ubuntu Bionic.)
The documentation generated for the cc_set_hostname module (as found e.g. at https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-hostname ) includes the paragraph: ==== Module frequency: per instance ==== However, looking carefully at the /var/log/cloud-init.log log, I see that the module is actually executed during the "init-local" phase on every boot: ==== 2019-11-20 17:08:08,364 - util.py[DEBUG]: Cloud-init v. 19.2-36-g059d049c-0ubuntu2~18.04.1 running 'init-local' at Wed, 20 Nov 2019 17:08:08 +0000. Up 30.32 seconds. [...] 2019-11-20 17:08:08,411 - handlers.py[DEBUG]: start: init-local/check-cache: attempting to read from cache [check] [...] 2019-11-20 17:08:08,588 - handlers.py[DEBUG]: finish: init-local/check-cache: SUCCESS: restored from checked cache: DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net] [...] 2019-11-20 17:08:08,849 - cc_set_hostname.py[DEBUG]: Setting the hostname to diggle.doxpop.com (bionic) 2019-11-20 17:08:08,849 - util.py[DEBUG]: Reading from /etc/hostname (quiet=False) 2019-11-20 17:08:08,849 - util.py[DEBUG]: Read 7 bytes from /etc/hostname 2019-11-20 17:08:08,850 - util.py[DEBUG]: Writing to /etc/hostname - wb: [644] 7 bytes 2019-11-20 17:08:08,851 - __init__.py[DEBUG]: Non-persistently setting the system hostname to bionic 2019-11-20 17:08:08,851 - util.py[DEBUG]: Running command ['hostname', 'bionic'] with allowed return codes [0] (shell=False, capture=True) 2019-11-20 17:08:08,908 - atomic_helper.py[DEBUG]: Atomically writing to file /var/lib/cloud/data/set-hostname (via temporary file /var/lib/cloud/data/tmp8p193ijc) - w: [644] 56 bytes/chars with allowed return codes [0] (shell=False, capture=True) [...] 2019-11-20 17:08:08,932 - handlers.py[DEBUG]: finish: init-local: SUCCESS: searching for local datasources ==== This is because cmd/main.py:main_init() calls cc_set_hostname (via the _maybe_set_hostname() function) without checking the per-instance semaphore status. Based on the comments in main_init(), it looks like there are good reasons that the hostname gets updated on every boot... but currently the behavior does not match the cc_set_hostname documentation (and in particular, it overwrites a manually-changed /etc/hostname upon reboot even when the instance id is not changed). I'm not sure exactly how this should be worded, but it would be nice if the documentation included an explanation of exactly when the cc_set_hostname module is called. ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1854236 Title: documentation for cc_set_hostname module doesn't mention runs during "init" phase Status in cloud-init: New Bug description: (I'm using cloud-init 19.2 under Ubuntu Bionic.) The documentation generated for the cc_set_hostname module (as found e.g. at https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-hostname ) includes the paragraph: ==== Module frequency: per instance ==== However, looking carefully at the /var/log/cloud-init.log log, I see that the module is actually executed during the "init-local" phase on every boot: ==== 2019-11-20 17:08:08,364 - util.py[DEBUG]: Cloud-init v. 19.2-36-g059d049c-0ubuntu2~18.04.1 running 'init-local' at Wed, 20 Nov 2019 17:08:08 +0000. Up 30.32 seconds. [...] 2019-11-20 17:08:08,411 - handlers.py[DEBUG]: start: init-local/check-cache: attempting to read from cache [check] [...] 2019-11-20 17:08:08,588 - handlers.py[DEBUG]: finish: init-local/check-cache: SUCCESS: restored from checked cache: DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net] [...] 2019-11-20 17:08:08,849 - cc_set_hostname.py[DEBUG]: Setting the hostname to diggle.doxpop.com (bionic) 2019-11-20 17:08:08,849 - util.py[DEBUG]: Reading from /etc/hostname (quiet=False) 2019-11-20 17:08:08,849 - util.py[DEBUG]: Read 7 bytes from /etc/hostname 2019-11-20 17:08:08,850 - util.py[DEBUG]: Writing to /etc/hostname - wb: [644] 7 bytes 2019-11-20 17:08:08,851 - __init__.py[DEBUG]: Non-persistently setting the system hostname to bionic 2019-11-20 17:08:08,851 - util.py[DEBUG]: Running command ['hostname', 'bionic'] with allowed return codes [0] (shell=False, capture=True) 2019-11-20 17:08:08,908 - atomic_helper.py[DEBUG]: Atomically writing to file /var/lib/cloud/data/set-hostname (via temporary file /var/lib/cloud/data/tmp8p193ijc) - w: [644] 56 bytes/chars with allowed return codes [0] (shell=False, capture=True) [...] 2019-11-20 17:08:08,932 - handlers.py[DEBUG]: finish: init-local: SUCCESS: searching for local datasources ==== This is because cmd/main.py:main_init() calls cc_set_hostname (via the _maybe_set_hostname() function) without checking the per-instance semaphore status. Based on the comments in main_init(), it looks like there are good reasons that the hostname gets updated on every boot... but currently the behavior does not match the cc_set_hostname documentation (and in particular, it overwrites a manually-changed /etc/hostname upon reboot even when the instance id is not changed). I'm not sure exactly how this should be worded, but it would be nice if the documentation included an explanation of exactly when the cc_set_hostname module is called. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1854236/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
