yahoo-eng-team team mailing list archive

[Ian Johnson <1883122@xxxxxxxxxxxxxxxxxx>]

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