Remove cloud-init when using simple-init

When using simple-init, we are making an explicit choice
along the lines of "I want the simple tool to do the simple needful"
which works well, except when cloud-init tries to run because it
is already baked into the source image diskimage-builder started
with.

So what would happen is Glean would execute from simple-init,
and then cloud-init would get launched by default, and cloud-init
in some cases everything is DHCP, so suddenly any static
configuration, such as what might be in an attached configuration
drive, is stomped upon resulting in an unreachable instance if
DHCP is just not available.

If DHCP is available, generally this is not an issue and goes
un-noticed, yet can add a substantial amount of time to the
boot sequence "waiting" for meta-data endpoints which may
not exist.

Change-Id: I380b9638cd28f5771530089c558ef5ab638c0173
This commit is contained in:
Julia Kreger 2023-11-01 08:39:40 -07:00
parent 0576fadab8
commit 6df7921cb7
3 changed files with 12 additions and 0 deletions

View File

@ -9,6 +9,11 @@ present in the host cloud. Additionally, in environments where cloud-init
is not used, there are a couple of small things, like mounting config-drive
and pulling ssh keys from it, that need to be done at boot time.
.. note::
This element removes cloud-init as it can stomp on the configuration
applied by glean, resulting in additional problems for operators,
and a more difficult path troubleshooting.
Autodetect network interfaces during boot and configure them
------------------------------------------------------------

View File

@ -7,3 +7,5 @@ NetworkManager:
when: DIB_SIMPLE_INIT_NETWORKMANAGER != 0
NetworkManager-initscripts-ifcfg-rh:
when: DIB_SIMPLE_INIT_NETWORKMANAGER != 0
cloud-init:
uninstall: True

View File

@ -0,0 +1,5 @@
---
fixes:
- |
Use of the ``simple-init`` element now removes ``cloud-init``, in order
to prevent the two tools from clashing when booting a workload.