[00:01] <holman> meena: just put up a network refactor which affects FreeBSD if you have cycles for a review 
[00:04] <holman> https://github.com/canonical/cloud-init/pull/5117
[00:04] -ubottu:#cloud-init- Pull 5117 in canonical/cloud-init "Netops refactor" [Open]
[00:05] <holman> cjp256: it also includes the iproute2 style changes you requested a while ago
[01:32] <minimal> holman: just had a quick look at #5117 and noticed that in iproute2.py the add_route function is hardcoded for "-4" (IPv4)
[01:32] <minimal> is that right? could there not be a situation where IPv6 route(s) may be added?
[01:34] <minimal> this is only for ephemeral use, right? which could be SLAAC or DHCPv6 and RA could provide route(s)
[02:14] <holman> minimal: eod here but ill take a peak at that tomorrow 
[02:15] <holman> minimal: my guess is that the code that it replaced only used -4, but I agree that it should probably be made more generic
[02:17] <minimal> I guess it depends on whether any DataSource relies on IPv6 routes to get to a metadata server
[03:18] <holman> minimal: iirc the ones that I'm familiar with use SLAAC
[03:46] <minimal> holman: just about to add a note to your #5097 - it does not actually fix #5095 for me
[14:51] <holman> minimal: thanks for the ping on that one
[14:52] <holman> minimal: #5119 should address it
[14:52] <holman> #5097 was just a partial fix
[16:05] <meena> holman: any idea on the faith of https://github.com/canonical/cloud-init/pull/4820  ? (I've tested it, and it looks good to me, but maybe I don't really know what I should be testing for)
[16:05] -ubottu:#cloud-init- Pull 4820 in canonical/cloud-init "Respect runtime file locations" [Open]
[16:11] <holman> meena: I think we're just waiting on blackboxsw's feedback since he had some concerns 
[16:11] <holman> release stuff has taken priority 
[16:12] <holman> meena: and thanks for the review and testing on that 
[16:29] <meena> aye
[16:48] <minimal> holman: thanks for that additional fix
[16:48] <minimal> unrelated, are any of you watching the unfurling "xz" backdoor revelations?
[17:06] <meena> just saw, would love to know where that came from
[17:33] <minimal> meena: seems to point to either 1 of the 2 xz contributors or else their account being compromised
[17:34] <meena> either way, that sounds bad.
[17:35] <minimal> at least the effects are not widespread for several reason: only in past 2 releases, only targeting x86_64, not affecting musl (not sure about other non-glibc), only on systemd systems, only where openssh sshd (indirectly) using xz
[17:39] <minimal> hmm, this seems to point to that maintainer being involved: https://news.ycombinator.com/item?id=39866275
=== dbungert1 is now known as dbungert