[10:33] https://github.com/canonical/cloud-init/pull/1760 [10:33] Pull 1760 in canonical/cloud-init "Style: use relative imports" [Open] [19:18] am i seeing this right, that azure is the only thing that uses the blacklisted drivers? [19:22] meena: yes I think that is the case [21:26] This https://github.com/canonical/cloud-init/pull/1759 is now as finished as it will be without https://bugs.launchpad.net/cloud-init/+bug/1991024 [21:26] Pull 1759 in canonical/cloud-init "cc_ntp: add support for BSDs" [Open] [21:26] Launchpad bug 1991024 in cloud-init "distros/manage_service: add support to disable services" [Undecided, Triaged] [21:26] will also need tests I guess… [21:27] what's missing for https://github.com/canonical/cloud-init/pull/1758 to be merged, btw? [21:27] Pull 1758 in canonical/cloud-init "Distro manage service: Add OpenBSD support" [Open] [22:20] meena: +1 for an eye towards platform independence in planned work [22:20] meena: saves us all future rework, many thanks :D [22:21] * meena has been platform independent since she started working on Solaris in her first job… [22:24] nice :) [22:24] anyone here got a sysv-init system that's… not a BSD? [22:25] I just realized that sysvinit maps ` "enable": [service, "start"],`, which is not the case on BSDs… where… enable is…enable. [22:26] meena: I helped decommission some old rhel v5 boxes once upon a time, I assume that's the closest I've gotten to sysvinit (besides firing up bsd vms) [22:27] holman: hah [22:30] i was gonna ask minimal, but now he's gone [22:30] they aer bac [22:30] k [22:30] they are back [22:32] meena: Hi, dodgy connection here lol [22:32] minimal: does alpine's "service" have an "enable" / "disable" ? [22:41] meena: I don't believe so. Alpine uses OpenRC rather than sysvinit and "service" is a softlink to OpenRC's "rc-service" [22:43] if you're referring to adding a service to a runlevel that would be "rc-update add " [22:45] minimal: so service enable won't do anything [23:01] in that case, I might just extend manage_service in FreeBSD [23:01] "service enable rngd": "service: service 'enable' does not exist" [23:02] "service rngd enable": "rngd: unknown function 'enable'" [23:02] minimal: aye, thanks [23:02] https://github.com/canonical/cloud-init/pull/1758 ← I'll probably just do that after this PR is merged [23:03] Pull 1758 in canonical/cloud-init "Distro manage service: Add OpenBSD support" [Open] [23:05] meena: in cloudinit/distros/alpine.py: init_cmd = ["rc-service"] so I don't know if it ever uses "service" rather than "rc-service" anyway [23:05] minimal: but that still means it can't enable/disable services… [23:06] anyway, bed time now. [23:08] meena: I've never tried or needed to to enable/disable a service in cloud-init config [23:10] minimal: most linux systems enable a service if you install it, or? [23:12] right, i wanted to goto bed. [23:14] meena: it depends. With Alpine, nope, packages don't enabled their services automatically just because they are installed [23:16] minimal: so if someone was to extend the rsyslogd module to support alpine, they would need an enable/disable thingy [23:16] meena: cloud-init's rsyslog module already works with alpine, I use it myself [23:17] I enable the rsyslog service as part of building an Alpine disk image containing cloud-init [23:17] in the same way I enable chrony service as well [23:18] https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_rsyslog.py#L36 [23:18] meena: but that means you also disable the busybox syslogd? [23:18] so all cloud-init is doing is putting a config file in place… [23:19] meena: nope, I don't disable busybox syslogd as it would be enabled if I'd enabled in the first place ;-) [23:19] s/be enabled/only be enabled/ [23:20] aye [23:21] my opinion of creating a cloud-init disk image (whether Alpine or something else) is that it is more involved that just installing cloud-init onto an existing OS disk image - there may be work to remove some files with config that shouldn't be present (i.e. hostname/domain/IP info), there will be installation of some basis services like NTP, Syslogd, and SSHd (only openssh for now but I'd like to add dropbear and tinyssh support in the future) [23:22] s/basis/basic/ [23:23] I don't disagree, I'd just like some modules to be a little more versatile… [23:23] basically, there's nothing wrong with FreeBSD's syslog, but if someone wants to use rsyslog it would be cool if they could just try it [23:24] meena: you're expecting Chrony or Busybox ntpd, or Syslogd / Rsyslog to be installed during cloud-init's run? [23:24] and then in their next iteration, they could then just build the image with syslogd disabled and rsyslogd installed and enabled, and cloud-init just does the config [23:25] minimal: the ntp module installs chrony or ntp/d or whatnot, the rsyslogd module does… who knows what [23:25] it puts a config file somewhere and restarts a service [23:26] meena: you're right, I forgot that cc_ntp supports installation, I've never tried it [23:26] and puppet, and ansible and chef, and salt, too [23:27] they install the thing, configure it, and start it [23:27] the restart isn't an issue, Alpine's rc-service supports that [23:28] enable tho…… [23:28] ansible doesn't install a daemon/service though AFAIK, it just runs ansible locally to pull a playbook from git, haven't looked at puppet, chef, or salt for c-i [23:29] true, true… alpine is an exception there [23:29] well to support enable on alpine I'd have to add support for "rc-update add ..." instead of it calling "rc-service" [23:29] Gentoo used to use openrc, they've moved to Systemd now AFAIK [23:30] i do not understand the appeal. [23:33] that's a different discussion/argument ;-) [23:34] minimal: i mean that's.. not true? [23:34] even if enable/disable support was added to c-i for Alpine there'd still be (for all distros) the issue you pointed out of needing to disable "rival" services, so cc_ntp would need to disable busybox ntp (and others) if chrony was enabled, cc_rsyslog would need ot disable Busybox syslogd or syslog-ng, etc [23:34] minimal: we just support both [23:34] (and have for many years) [23:35] sam_: referring to Gentoo? I'd though the move of OpenRc from Gentoo to its own git repo related to Gentoo's move to systemd, perhaps I picked that up wrong [23:36] you did [23:36] that was just because it's an independent project [23:36] (and it's used by multiple distros) [23:36] sam_: perhaps I'm getting it confused with eudev? [23:37] i think so, although we didn't move away from that either, we still have it, but we stopped pretending it was actively maintained by us (the main person who was doing it is too busy now) [23:37] so it became a 3rd party thing [23:37] but we still have udev on openrc systems, just split out from systemd [23:37] sam_: right, that's probably what was at the back on my mind lol [23:37] yeah that makes sense now you said it [23:37] I should've thought! [23:38] I was thinking, the openrc repo thing was like.. 10 years ago, surely [23:38] sam_: my memory's not getting any better with age ;-) [23:43] minimal: you are not of minimal age? like, 7 or 21, or whatever else counts as young [23:49] wrong side of 50 ;-) [23:49] been there, done that, wrote the book, lol [23:55] * meena turned 38 on the coolest date this year [23:55] I wonder if anyone turned 22 on that date [23:56] and if they did, i hope they got to celebrate instead of being sick with Covid [23:56] I'll give it another shot in 200 years 🧛🏻‍♀️