[17:37] <chillysurfer> good day, all! i'm curious under what circumstance a network interface would be renamed to `cirename0`? briefly looking through the code isn't extremely obvious what the condition would be
[17:41] <powersj> chillysurfer, rharper's previous comment in https://bugs.launchpad.net/cloud-init/+bug/1852162 might be helpful
[17:41] <ubot5> Ubuntu bug 1852162 in cloud-init "Some NIC didn't get the IP when attach multiple nics after VM provisioned on azure" [Undecided,Expired]
[17:57] <chillysurfer> powersj: so basically cloud-init uses cirename0 so that after a different interface setting (i.e. changed entwork adapters) it'll still retain the original and configured adapter names?
[17:58] <powersj> chillysurfer, I think that is how I read ryan's comment as well
[17:58] <chillysurfer> powersj: perfect thanks!
=== vrubiolo1 is now known as vrubiolo
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
[18:54] <powersj> Krikke, the command you were looking for earlier is cloud-localds: https://cloudinit.readthedocs.io/en/latest/topics/faq.html#cloud-localds
[18:54] <powersj> handy way to produce an ISO with user data or metadata to then pass the disk to an instance
[18:55] <powersj> the doc above has some examples using qemu
[19:05] <rharper> chillysurfer: the 'cirename' prefix is used as a swap value;  if we need to rename an interface (set-name in config); if we need to swap names (eth0 and eth1 names are reversed from a previous boot), then we cannot just rename eth0 to eth1; in those cases we use a cirenameX as placeholder;   see cloudinit/net/__init__.py:_rename_interfaces();
[19:28] <chillysurfer> rharper: thanks!! that makes total sense
[19:28] <rharper> chillysurfer: sure;  in some failure paths, you'll see cirenameX still around;  are you seeing that ?
[19:38] <chillysurfer> rharper: i don't think so but i'll validate that as well
[20:13] <Krikke> powersj: ah ok, the terraform scripts do it for me :)
[23:26] <giesen> Arghh lost hours because the documentation for static routes is partially incorrect with regards to Network Configuration v2. Submitted a pull request to fix it :))