[15:01] <meena> what, even, does that do? https://github.com/canonical/cloud-init/pull/1935#issuecomment-1375940643
[15:01] -ubottu:#cloud-init- Pull 1935 in canonical/cloud-init "RFC: Option to warn on duplicate mac" [Open]
[15:45] <meena> (I mean, a switch with all mac addresses configured the same)
[15:55] <frickler> sonic does that
[18:45] <holmanb> falcojr: ehh, I'm rethinking my earlier +1 to calling lp:1999680 a wontfix after giving a workaround.
[18:45] -ubottu:#cloud-init- Launchpad bug 1999680 in cloud-init "Fix remove machine-id" [Undecided, Incomplete] https://launchpad.net/bugs/1999680
[18:51] <falcojr> holmanb: I never dug into what this meant, but I thought you said that indicates somehow that it's a dirty boot
[18:51] <falcojr> because your workarounds are just leaving an empty machine-id, right?
[18:53] <holmanb> yes and yes
[18:55] <falcojr> so what are you proposing? 
=== EugenMayer598 is now known as EugenMayer59
=== EugenMayer594 is now known as EugenMayer59
=== EugenMayer592 is now known as EugenMayer59
[20:28] <holmanb> I think that removing the flag might be best. Currently it doesn't reduce the amount of information a user requires to generate an image, and it describes next boot as generating a new machine-id (a promise we can't guarantee - a source of confusion).
[20:28] <holmanb> As a newer build-time feature it seems something that's a bit less of a pain point to change on users.
[20:30] <holmanb> The original addition was well-intentioned, but I think we hit a bit of complexity that wasn't originally forseen. And as a newer image-build helper flag that effectively does `rm /etc/machine-id`, I don't see this as a high-value thing that should be unchangable.
[20:36] <holmanb> Removing a feature after addition doesn't feel good, but also neither does introducing a feature that doesn't do what it says it does then choosing not to fix it.
[20:45] <holmanb> I guess we could just update the --help output and docs, but I think I'd still not like having an interface that solves the machine-id problem in some cases but not others. Since it doesn't solve the problem in all cases the user is still going to have to truncate -s 0 in some cases and --machine-id in others. What's the point of keeping --machine-id if they still need to customize the command that gets ran based on version and 
[20:45] <holmanb> image composition (container vs vm, presence of systemd-firstboot, etc)?
[20:51] <blackboxsw> holmanb: falcojr I'll see if I can come up with a good reason to keep cloud-init clean --machine-id. Given that it only seems to get regenerated on lxc containers by default, there are plenty of corner-cases that seem to fall over. What I had wanted to do was find the cupbable bit of code in lxc container land that is actually triggering the creation of /etc/machine-id (as journald starts at a point in time after it is created.
[20:51] <blackboxsw> s/cupable/culpable/
[20:53] <blackboxsw> also in testing ec2/azure with the removed /etc/machine-id  I find the VMs don't come back after that file is removed. I'm setting up remote console to check what gives there w/ cloud-init behavior
[20:55] <blackboxsw> and this is a problem with kvm instances in LXD too as they don't recreate /etc/machine-id across reboot 
[20:55] <waldi> blackboxsw: debian does not support working without /etc/machine-id in almost all circumstances and i doubt that ubuntu did change that
[20:56] <waldi> removing /etc/machine-id triggers first boot behaviour, which is interactive
[20:56] <waldi> (since systemd enabled those services some versions ago)
[20:57]  * waldi is the culprit…
[20:59] <waldi> so truncating machine-id is the way to go, as it triggers re-creating one, but not first boot
[21:06] <holmanb> also just a heads up to anyone that regularly looks at cloudinit.readthedocs.io -> some pretty big layout changes to the docs just dropped, so you might want to re-familiarize
[21:07] <holmanb> The general idea was to categorize content type under tutorials / how-to / reference / explanation. This will probably feel unfamiliar initially, but hopefully this makes content more discoverable (esp for new users) in the long run.
[21:08] <holmanb>  I'm setting up some redirects for the higher volume pages to avoid broken links from external sites, bookmarks, etc.
[21:11] <blackboxsw> waldi thx. the intent was to minimally guanantee that cloned VM images don't wake up with the same /etc/machine-id as duplication of "machine identity" for some remote services lead to issues with dep-duplication based on IP address and/or MAC address. Most cloud-cloned images take care of this setup for folks and ensure uniqueness across clone image relaunch, but folks manually creating golden images don't have that knowledge.
[21:11] <blackboxsw> ... and it seems neither did I in many cases
[21:11] <blackboxsw> s/dep-duplication/deduplication/
[21:26] <falcojr> so now I'm going back to my original position that we should just truncate /etc/machine-id XD
[21:26] <falcojr> it's what ubuntu images do in jammy and later, and that behavior might be backported
[21:29] <falcojr> AFAIK, the only difference is whether units with 'ConditionFirstBoot=yes' will run, which are none on Ubuntu systems
[21:29] <falcojr> if we put an "uninitialized", then I think they will run and it will act like a first boot