yahoo-eng-team team mailing list archive

[Dan Watkins <1883122@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: cloud-init
     Importance: Undecided
         Status: 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