| 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:01 | |
| meena | (I mean, a switch with all mac addresses configured the same) | 15:45 |
| frickler | sonic does that | 15:55 |
| 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:45 | |
| 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:51 |
| holmanb | yes and yes | 18:53 |
| falcojr | so what are you proposing? | 18:55 |
| === EugenMayer598 is now known as EugenMayer59 | ||
| === EugenMayer594 is now known as EugenMayer59 | ||
| === EugenMayer592 is now known as EugenMayer59 | ||
| 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:28 |
| 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:30 |
| 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:36 |
| 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:45 |
| 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:51 |
| 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:53 |
| 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:55 |
| waldi | removing /etc/machine-id triggers first boot behaviour, which is interactive | 20:56 |
| waldi | (since systemd enabled those services some versions ago) | 20:56 |
| * waldi is the culprit… | 20:57 | |
| waldi | so truncating machine-id is the way to go, as it triggers re-creating one, but not first boot | 20:59 |
| 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:06 |
| 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:07 |
| holmanb | I'm setting up some redirects for the higher volume pages to avoid broken links from external sites, bookmarks, etc. | 21:08 |
| 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:11 |
| 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:26 |
| 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 | 21:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!