[12:44] <meena> I think minimal's alpine manage_service specialisation should probably become the default sysv-init implementation 
[14:10] <minimal> meena: I assume you mean OpenRC, rather than sysv-init
[14:11] <minimal> the only other cloud-init supported distro that uses/can use OpenRC is Gentoo - it support both systemd and OpenRC but I'm not sure anyone actually uses cloud-init with Gentoo and OpenRC
[14:12] <minimal> I did mention my manage_service changes to a Gentoo person but didn't get any feedback
[14:52] <meena> minimal: yesno. I think Debian's sysv-init should also have update-rc
[14:59] <minimal> ah right, I forgot Debian still has sysvinit support. Yes there is service / update-rc.d if the init-system-helpers package is installed. for both Gentoo and Debian that would mean checking for systemctl program first before falling back to sysvinit/openrc commands I guess
[15:06] <meena> that's what we do
[15:06] <meena> uses_systend()
[15:07] <meena> which is hopefully cached
[15:07] <minimal> I guess there just hasn't been any interest/anyone using c-i on those distros without systemd
[15:07] <minimal> I assume the official Debian cloud images have systemd
[15:08] <minimal> don't believe Gentoo has any official cloud images at all
[15:09] <meena> there's still all those freaks who forked Debian, making sysv-init default
[15:10] <meena> but who knows if they're anywhere close to any cloud system
[15:10] <minimal> Devuan
[15:14] <minimal> they do have c-i 22.4.2 packages (from Debian), however I don't see any Devuan cloud images
[15:18] <meena> Devuan reminds me of people who build their entire personality on spite
[16:01] <holman> minimal: Google has a Gentoo-based distro that they have images for, but I don't remember which init system they use.
[16:03] <holman> also we have a pep517 bug that iirc was affecting OpenRC but not SystemD on Gentoo
[16:43] <minimal> holman: am trying to figure out how to deal with some network config v2 related issues
[16:44] <minimal> so gateway4 & gateway6 were recently deprecated in netconfig v2 because they have been deprecated in netplan, right?
[16:51] <falcojr> Correct 
[16:52] <minimal> ok, there's two things related to this that I'm trying to deal with
[16:52] <minimal> (1) netplan defines accept-ra as boolean, but the Linux kernel has 3 values for that, 0,1,2
[16:53] <minimal> so there's no way for me to set "accept_ra: 2" in an eni using netconfig v2
[16:55] <minimal> (2) the eni renderer (and I assume other renderers) treats gateway4/gateway6 differently than "routes:" for default IPv4/v6 routes - which means that ifupdown/(Alpine) ifupdown-ng will NOT use "onlink" for adding default routes via "routes:" but will for gateway4/gateway6
[16:57] <falcojr> for 2, I think that could be solved by pulling the on-link key into v2
[16:59] <falcojr> not sure what can be done about 1
[17:00] <minimal> falcojr: for "on-link" that requires it to be explicitly provided, currently ifupdown/ifupdown-ng always specify "onlink" to "ip route add default" so all default routes (whether the gw is in or outside of the subnet) get it set
[17:01] <minimal> so if I use "gateway4" with eni and a /32 IPv4 address then the default route is set correctly
[17:03] <minimal> if I use "routes:" with eni and a /32 IPv4 address instead the route is not set correctly (it would if I change the eni renderer to treat "routes:" for default in the exactly same way it treats gateway4/gateway6 - i.e. writes a "gateway:" entry in the appropriate inet/inet6 section rather than "post-up" entry)
[17:03] <minimal> ^^ of eni file
[17:03] <minimal> that's one of the things i'm currently working on
[17:05] <falcojr> minimal: sorry, don't remember eni syntax much. Are you saying it uses separate syntax for the default route vs other routes?
[17:05] <minimal> falcojr: yes, it doesn't define a default route, it has a "gateway <ip address." in the iface section
[17:06] <minimal> that then triggers ifup (in both ifupdown & ifupdown-ng) to do a "ip route add default ......"
[17:08] <falcojr> but it shouldn't be hard in the v2 config to see if somebody has defined a default route, right?
[17:09] <minimal> network_state.py passes default routes specified via gateway4/6 to the renderer differently than default routes specified via "routes:"
[17:11] <falcojr> right, yeah, we'll need to update the affected renderers appropriately
[17:12] <minimal> that's what I'm trying to figure out how to do for eni currently
[17:14] <minimal> re the other issue, eni manpage says:
[17:14] <minimal> accept_ra int   Accept router advertisements (0=off, 1=on,  2=on+forwarding). Default value: "2"
[17:15] <minimal> whereas netplan docs say:
[17:15] <minimal> accept-ra (bool)   Accept Router Advertisement that would have the kernel configure IPv6 by itself. When enabled, accept Router Advertisements. When disabled, do not respond to Router Advertisements. If unset use the host kernel default setting.
[17:15] <falcojr> minimal: Can you detect a default route specified in v2 and translate to the eni gateway?
[17:18] <minimal> yes, that would require search for "default", "0.0.0.0/0", and "::/0" and then also removing those from the routes list so they don't get renderered as additional routes
[17:18] <minimal> that was what I had in mind
[17:21] <falcojr> yeah, that makes sense
[17:22] <minimal> falcojr: I intend to put the various v1 and v2 netconfig files I'm testing in a Github repo, I'll drop you a link when I do that
[17:22] <falcojr> that'll be useful, thanks
[17:23] <minimal> trying to cater for various realistic scenarios, e.g. DHCP only, static IPv4/v6 only, static plus SLAAC, etc