yahoo-eng-team team mailing list archive

[James Falcon <1883122@xxxxxxxxxxxxxxxxxx>]

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