=== EugenMayer590 is now known as EugenMayer59
[11:56] <meena> oh ho! https://freshbsd.org/freebsd/src/commit/62a149bf621947fb7475c64b1ff04fe19fe16b29
[11:58] <meena> wonder if the requires and before are enough for it to run before cloud-init 
=== janitha76 is now known as janitha7
[13:36] <meena> aciba: maybe someone should've told github-actions bot, that ye are on holidays
[13:36] <meena> https://github.com/canonical/cloud-init/pull/1924 this needs a review
[13:36] -ubottu:#cloud-init- Pull 1924 in canonical/cloud-init "make the same authentication behavior for arm and x86 machine" [Open]
[13:37] <meena> this also needs a review https://github.com/canonical/cloud-init/pull/1925
[13:37] -ubottu:#cloud-init- Pull 1925 in canonical/cloud-init "fix for LP:1919045" [Open]
[13:54] <meena> https://github.com/canonical/cloud-init/pull/1931 this looks good?
[13:54] -ubottu:#cloud-init- Pull 1931 in canonical/cloud-init "network/netplan: add gateways as on-link when necessary" [Open]
[14:12] <aciba> meena: thanks for the ping, we will have a look on them.
[14:37] <waldi> hmm, why only "if necessary"? the flag does not break if it is not necessary
[14:39] <meena> waldi: hmm?
[14:40] <waldi> you can add the flag without adverse effects even if it is not strictly needed. reduces the special cases
[16:07] <meena> waldi: aye. 
[19:34] <falcojr> the gateway not in subnet returns
[19:34] <falcojr> https://bugs.launchpad.net/cloud-init/+bug/2000596
[19:34] -ubottu:#cloud-init- Launchpad bug 2000596 in cloud-init "Netplan: Improve support for directly (on-link) connected gateways" [Undecided, New]
[19:35] <falcojr> the "if gateway not in subnet then add 'on-link' to config" idea is interesting to me
[19:35] <falcojr> I'm trying to think if there's any reason that wouldn't work
[19:36] <falcojr> the only possible way that config can work is if the gateway is on-link anyway, so it seems like that'd be a safe change to make
[19:48] <meena> it's interesting that this is only failing in netplan
[20:16] <holmanb> > because ifupdown always adds the "onlink" flag to the gateway
[20:16] <holmanb> that's interesting
[20:17] <minimal> I don't think that'll work for Alpine currently as ifupdown-ng does not seem to have logic to use "onlink" in /e/n/i
[20:21] <falcojr> well I think this would be for netplan only, and only if the gateway doesn't belong to the subnet
[20:22] <minimal> falcojr: we were chatting before Xmas about some VPS providers that use /32 for IPv4 and also might use /128 for IPv6 and so the "on-link" stuff is relevant in general
[20:23] <falcojr> yeah...I saw most of that. Helpful to know how a gateway could be on a different subnet
[20:24] <minimal> well for a IPv4 /32 address the gateway of course has to be on a different subject ;-)
[20:25] <minimal> so Hetzner and OVH appear to allocate /32 addresses
[20:25] <holmanb> falcojr: with that most recent bug, couldn't they just use the kind of netplan config that they asked for support for (declaring `on-link: true` under `routes:`)?
[20:27] <holmanb> since they are on a system with netplan present it should just pass through
[20:42] <falcojr> holmanb: given that there's a network_data.json, this is probably an openstack config drive
[20:43] <falcojr> in that case you probably don't want your metadata hardcoded to a specific implementation
[20:43] <holmanb> ah
[20:43] <falcojr> but...we could also add some kind of on-link option to our network configs rather than guessing...but then we'd have to make sure we're rendering it correctly everywhere
[22:23] <holmanb> falcojr: adding an on-link option to our network configs wouldn't solve the config drive case, right?
[22:25] <falcojr> well you'd need updated metadata then
[22:25] <holmanb> right
[22:36] <holmanb> falcojr: making sure we're on the same page: by updated metadata you mean we'd need openstack to update the metadata format they send?
[22:38] <falcojr> correct
[22:59] <holmanb> I think guessing would probably work for configdrive -> netplan.
[23:00] <holmanb> Not sure what to suggest for alpine though.
[23:04] <holmanb> minimal: think ifupdown-ng would take a PR adding onlink to gateways for compatibility?
[23:05] <holmanb> here maybe? https://github.com/ifupdown-ng/ifupdown-ng/blob/34753136b86d5b1d5df2b60b22f1bfac16f28416/executor-scripts/linux/static#L36
[23:36] <minimal> holmanb: you mean in generic, rather than triggered by some /e/n/i option?
[23:36] <minimal> s/generic/general/