This bug is believed to be fixed in cloud-init in version 22.4. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: In Progress => Fix Released
--
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/1883122
Title:
`cloud-init status` should distinguish between "permanently disabled"
and "disabled for this boot"
Status in cloud-init:
Fix Released
Bug description:
Using ds-identify and a systemd generator, cloud-init can detect that
it should disable itself for a particular boot when there is nothing
for it to do. However, if on the next boot a datasource becomes
applicable (e.g. a NoCloud/ConfigDrive device is presented to the
system) then cloud-init will _not_ be disabled, because ds-identify
will detect an applicable datasource.
If users want a stronger guarantee that cloud-init will not run, then
they can touch /etc/cloud/cloud-init.disabled, or add cloud-
init=disabled to their grub configured kernel command line. When they
do so, cloud-init will _never_ run, regardless of the applicability of
datasources.
In both of these cases, `cloud-init status` reports "disabled". This
means that users who want to confirm that cloud-init will never run in
the future given its current configuration have to check all the
potential ways that cloud-init might be permanently disabled
(/etc/..., kernel cmdline, maybe other options that I haven't
documented here, maybe new options in the future) themselves.
We should distinguish between these two modalities of "disabled" for
users in our status output.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1883122/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
