yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #83754
[Bug 1883122] Re: `cloud-init status` should distinguish between "permanently disabled" and "disabled for this boot"
What we would like to be able to do in snapd is positively distinguish
between the following cases:
1) a cloud-init.disabled file was placed, thus disabling the generator and ensuring that cloud-init will never run "by itself" if the device was rebooted at that point in time with the same disk and image and everything
2) no cloud-init file was placed, and cloud-init has not been "triggered" on this boot, but it is not "fully disabled", and if a CDROM or USB drive with NoCloud stuff was attached on next boot, it could still run
We currently handle this in snapd by just checking first if the cloud-
init.disabled file exists, and if it doesn't but `cloud-init status`
still says "disabled" we consider that to be "untriggered".
** Changed in: cloud-init
Status: Expired => 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/1883122
Title:
`cloud-init status` should distinguish between "permanently disabled"
and "disabled for this boot"
Status in cloud-init:
New
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
References