6df7921cb7
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
6 lines
161 B
YAML
6 lines
161 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Use of the ``simple-init`` element now removes ``cloud-init``, in order
|
|
to prevent the two tools from clashing when booting a workload.
|