[00:29] <lesbraz> "<minimal> so Hetzner and OVH appear to allocate /32 addresses" → I work for OVH, that's the reason I'd like to see this implemented :); although my findings were related to bare metal, it's cool if it also helps with VPS
=== lesbraz is now known as sbraz
[00:33] <sbraz> holmanb, falcojr: "in that case you probably don't want your metadata hardcoded to a specific implementation" → exactly, we use the same config for all Linux distros for now; we'll add an exception for Ubuntu where we will add a route to gw/128 via :: to be able to reach it, kinda like NetworkManager does (until the bug is fixed)
[00:36] <sbraz> waldi: "you can add the flag without adverse effects even if it is not strictly needed" → yeah i'm not against doing this option either since ifupdown does it; i wasn't aware of ifupdown-ng though and i haven't yet checked if ifupdown2 works properly with these gateways (we'd need it for Proxmox 7)
[00:54] <minimal> sbraz: interesting, I talked to a couple of people recently using cloud-init with OVH, one with Bare Metal "Cloud" and the other with the usual OVH Cloud - in one case Openstack ConfigDrive2 was used as the DataSource and in the other case the Openstack metadata server ("OpenStack DS"). In the ConfigDrive situation the presented network config was a bit "nuts"  - there was a /32, a /33, a /34, a /35 through to /128 routes defined (from memory)
[00:57] <minimal> meena: no idea, I'm still seeing "AssertionError: Unexpectedly used subp.subp"
[00:58] <minimal> meena: perhaps I should change the "cloudinit.distros.networking.subp.subp" to something else like "cloudinit.distros.subp.subp"?
[03:04] <minimal> holmanb: I tested a modified ifupdown-ng with /32 IPv4 and /128 IPv6 on Alpine and it works fine (apart from issue I've already experienced with using "routes" instead of gateway4/gateway6 for /e/n/i)
[03:05] <minimal> I'll aim to raise an upstream PR for ifupdown-ng to add the change and also to get it applied to alpine's package (assuming upstream doesn't do a release)
[03:24] <holmanb> minimal: nice work, let me know how it goes
[03:27] <holmanb> Also if you'd like a review on the PR give a shout
[04:05] <minimal> holmanb: the routes vs gateway4/gateway issue is a difference in the resultant /e/n/i files generated and some concerns around that - but I've got too many c-i related things in play currently to look into that yet
=== cpaelzer_ is now known as cpaelzer
[12:35] <sbraz> is there a bot to leave notes here? i'd like to leave a note for minimal
[12:39] <aciba> sbraz: Canonical exposes an IRC log here: https://irclogs.ubuntu.com/2023/01/04/%23cloud-init.html
[12:39] <aciba> I am pretty sure he is aware of it
[12:40] <aciba> he / she *
[13:39] <meena> sbraz: minimal reads the logs after coming online
[13:39] <meena> aciba: if you don't know, you can always say "they" in English ;)
[13:51] <aciba> thanks meena
[14:41] <sbraz> meena: thanks, so, minimal, when you join, i'm not very familiar with all the openstack infra but yeah they do use the openstack datasource; for bare metal, we do use a configdrive and we currently set the ipv6 to a /56 even though the actual subnet is /64, and we add routes via the gateway to everything that is part of the /56 but not the /64, hence the dozens of routes :/
[14:41] <sbraz> this is what i'm aiming to fix
[14:49] <meena> sbraz: which cloud is this? 
[14:53] <sbraz> meena: i work for ovhcloud, was that your question?
[14:54] <meena> sbraz: yes
[17:14] <esv> hey folks, I am looking at the documentation for v21.4 on Merging User-Data sections and I am a bit confused how recurse-list is applied to dictionaries 
=== smoser1 is now known as smoser