yahoo-eng-team team mailing list archive

[Brett Holman <2003121@xxxxxxxxxxxxxxxxxx>]

Resetting machine-id at runtime would be a pretty big break from current
expectations, and correct implementation would require foreknowledge of
services using machine-id that are provided in an image. The potential
for bugs due to implementation complexity, potential for boot speed
regression caused by services delaying until after machine-id is reset,
and expected future burden of such a feature due to changes in services
and variation in Ubuntu and other distros makes the perceived risk of
this feature outweigh the benefit. These complexity, risk, and potential
boot speed issues are not present when machine-id is correctly set at
boot time, so I'm hesitant to move forward with this request.

I'll mark this "Won't Fix" for now.

In the meantime, I'd like to point users experiencing the same issue
towards our build recommendation[1], specifically the --machine-id
option.

[1] https://cloudinit.readthedocs.io/en/latest/reference/cli.html#clean

** Changed in: cloud-init
       Status: New => Won't Fix

-- 
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/2003121

Title:
  machine-id is not reset when instance-id changes

Status in cloud-init:
  Won't Fix

Bug description:
  As discussed in #ubuntu-server just now, it's expected that cloud-init
  will ensure that machine-id is not carried over when a VM is cloned
  and this is detectable by an instance-id change.

  This would align behaviour with ssh host key regeneration behaviour.

  Actual behaviour: currently if a VM is cloned and the instance-id
  changes, /etc/machine-id remains the same.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2003121/+subscriptions