=== cpaelzer_ is now known as cpaelzer
sbrazfalcojr: i meant that "addr" gets *checked* before by something else, sorry, i forgot the word in my comment :P17:14
sbrazfalcojr: you're james falcon, right? :P17:15
falcojrsbraz: Yes, I am. And thanks, that makes sense17:20
minimalholmanb: PR raised with upstream ifupdown-ng for "onlink", also raised patch to existing Alpine ifupdown-ng package17:21
minimalare there any RHEL/Fedora experts in the channel?17:22
sbrazminimal: i'm no expert but maybe i can ask around if necessary, i know someone from cloudlinux17:54
sbrazminimal: what are the hopes that debian switches to ifupdown-ng at one point?17:55
minimalsbraz: no idea if Debian would switch from ifupdown to ifupdown-ng or whether they'd go in the direction of systemd-networkd instead17:57
minimalsbraz: RHEL/Fedora question is regarding an aspect of their handling of CA certs, haven't found the info I'm looking for online so far17:57
sbrazwe've had numerous issues with ifupdown in the following case: ipv4 dhcp+ipv6 static; at boot a dhcp request is issued, the network comes up, something sends an IPv6 RA (or something, i'm no ipv6 expert), ifupdown either can't add the static ipv6 address or it's the gateway that's duplicate, networking.service fails; dhcpd gets killed; $LEASE hours later, the IPv4 expires, server is unreachable; reboot 17:59
sbrazthe server → it works for $LEASE more hours before failing again :P18:00
sbrazthey fixed the route problem in debian 11 by using "ip ro replace default" instead of "ip ro add default"18:00
sbrazand i think they also run "ip addr flush" now so the address can't be duplicate any more18:01
sbrazbut still, the fact that ifupdown can fail (for a number of reasons) and that the dhcp-obtained ipv4 stays there even though the dhcp client is still dead… it's not ideal18:02
minimalsbraz: how are you specifying the network config? via ConfigDrive2? via Openstack metadata server? what's the exact network config provided to cloud-init in that situation?18:02
sbrazminimal: via configdrivev2, and with debian 11 we don't have issues any more because the generated e/n/i file works perfectly18:03
sbrazbut with debian 10 we still had issues so we added a bunch of pre-up scripts18:03
minimalhmm, wonder what changed between 10 and 1118:04
minimalam interested to see any example of your ConfigDrive network file as the only one I've seen to date (elsewhere) was a bit "wacky"18:04
sbrazminimal: i know one of the things that helped was https://salsa.debian.org/debian/ifupdown/-/commit/aa9b12d76a8cc3fb919fc64d624a45f3eca86444 but it's been committed a while back18:15
-ubottu:#cloud-init- Commit aa9b12d in debian/ifupdown "Default accept_ra to 0 when gateway is set (Closes: #775660)"18:15
sbrazbut sometimes i think RAs were still received before ifupdown could start18:16
sbrazhttps://salsa.debian.org/debian/ifupdown/-/commit/3fb794b2dc1f16da09409522826142ef5e226ddc helped fix the problem18:16
-ubottu:#cloud-init- Commit 3fb794b in debian/ifupdown "Fix race condition adding a static IPv6 default route on RA networks"18:16
sbrazand https://salsa.debian.org/debian/ifupdown/-/commit/fe9fb5882ab5d238122d986454b0d156477bc8d0 is helpful too as it flushes leftover ips18:17
-ubottu:#cloud-init- Commit fe9fb58 in debian/ifupdown "Flush automatically assigned addresses on ifup when accept_ra=0."18:17
sbrazi guess the one thing that changed from 10 to 11 is the route replace, the rest was here before18:20
minimalyeah we were chatting on here before Xmas about the handling of DHCPv6 vs static v6 vs SLAAC etc with regarding to network config v218:56
esvhey folks, does cloud-init treat instances restored from a recovery vault as a cloned/new instance? files under /var/lib/cloud/sem and /var/lib/cloud/instance/sem do not seem to be updated, however per-instance scripts are being run again19:56
=== EugenMayer592 is now known as EugenMayer59
blackboxswesv on most platforms when a new instance is launched from a cloned image, the platform/cloud itself provides a new instance-id in meta-data or in DMI information for the VM.  When cloud-init sees a new instance-id that is different than /var/lib/cloud/data/previous-instance-id it will log something like: " Update datasource metadata and network config due to events: boot-new-instance21:43
blackboxswyou can check quickly in logs if instance id changed with 'grep "previous iid found to be" /var/log/cloud-init.log"21:43
blackboxswlast quote should be a single quote ' 21:44
esvright after posting this found a hit on what azure does and indeed the doc says it would change, my confusion comes from the fact that /var/lib/cloud/instance/sem files have the same i-node timestamp as the original creation date.21:52
esvguess I need to wrech a couple of my lab servers and see what happens 21:53
esvthnx for the tip, will search on that.21:53

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!