[10:10] <meena> I have a question about the init scripts: Is there every any reason to only enable one of the cloud-init daemons?
=== esv_ is now known as esv
[13:46] <minimal> meena: you mean scripts rather than daemons? There's only 1 "daemon" with cloud-init, the hotplug script
[14:13] <blackboxsw> meena: not that I can think of. each init script corresponds to the 4 boot stages. Different parts of cloud-init discovery or configuration run during each of the boot stages. If you don't run init-local or init stages you risk not discovering certain datasources which are only detected in init-local or init stage. If you skip modules-config or modules-final you don't apply parts of the user-data configuration in the cc_* modules.
[14:36] <meena> blackboxsw: aye.
[14:36] <meena> meena: what's the hotplug script? and does that work on not-linux? (does it even work on Alpine?)
[14:38] <minimal> meena: it's for handling hotplugged network interfaces, i.e. on AWS
[14:38] <minimal> the shipped script does not work on (base) Alpine as it is written in Bash but I have packaged a derivative that runs on sh/ash
[14:45] <meena> how does a script run as daemon?
[15:05] <minimal> meena: in the sense that it runs and keeps running rather than runs for a few seconds and exits
[15:05] <minimal> it listens on a pipe (from memory) and processes data from it
[15:05] <meena> ah,
[15:06] <minimal> basically (again from memory) it listens for udev events and reacts to them
[15:09] <meena> minimal: this thing? https://github.com/canonical/cloud-init/blob/HEAD/tools/hook-hotplug
[15:10] <minimal> yeah
[15:13] <meena> how do people manage to write 20 lines of shell code, that's not sh compatible?
[15:14] <minimal> https://git.alpinelinux.org/aports/tree/community/cloud-init/03-hook-hotplug-sh.patch
[15:18] <meena> minimal: oh, right, no arrays, … brrr…
[15:18] <meena> but, still, easier to fix that than expected
[15:18] <meena> how come you didn't push it upstream?
[15:19] <minimal> I haven't tested in yet, hotplug is only support by Ec2, ConfigDrive2, and OpenStack datasources from memory
[15:23] <minimal> meena: in a related note I have a patch for doas support which I haven't upstreamed as doas is fragmented (Alpine is using opendoas) and it relies in functionality only currently present in opendoas
[15:25] <meena> meena: boooo
[15:25] <meena> i mean, that sounds great
[15:26] <minimal> basically doas only supports a single config file /etc/doas.conf whereas opendoas added also support for a directory where multiple files can be read from - so my doas support acts in a similar way to c-i sudo support of creating file in /etc/doas.d/
[15:27] <meena> speaking of sudo / doas: somebody should really make the sudo thing idempotent
[15:28] <meena> https://gist.github.com/620feecb55db46cdeab5c12fa986ae61
[15:33] <minimal> doesn't the contents of /etc/sudoers.d/90-cloud-init-users get replaced rather than appended to?
[15:34] <minimal> haven't checked the code yet...
[15:34] <meena> not on my machines
[15:34] <meena> every time i run cloud-init clean -sl i get a new entry
[15:36] <minimal> add, the code appends to file is it exists
[15:37] <minimal> function write_sudo_rules in distros/__init_.py or freebsd.py, netbsd.py
[15:39] <meena> minimal: indeed, i just saw that, too
[15:39] <meena> so it's a feature
[15:41] <meena> I think we should read the file, and if the contents is the same as what we have, skip writing it
[15:42] <minimal> I think just write the file regardless (unless the intention was for the image creator to prepopulate the file, in which case couldn't user-related entries in /etc/clould/cloud.cfg achieve the same?)
[15:42] <minimal> write as in overwrite
[15:46] <meena> yeah, i think overwrite would be less… surprising.
[15:47] <minimal> meena: BTW I noticed you'd raised a launchpad issue some time ago about freebsd support for cc_ca-certs
[15:47] <minimal> I'm doing some work with that code currently
[15:47] <meena> minimal: reminder to myself, to implement it
[15:47] <minimal> is there a clear document as to how freebsd handles certs?
[15:48] <minimal> I'm already trying to figure out if the existing RHEL support is fully functional or not
[15:48] <meena> minimal: usually, our man pages are pretty good ;) https://man.freebsd.org/certctl
[15:48] <meena> and if not, that's a bug.
[15:49] <minimal> ok, i'll have a look and try and add FreeBSD support while I'm at all
[15:50] <meena> it's on my radar, but my radar is currently beeping out of control
[15:51] <minimal> well I'm rejigging the code anyway so it's not much more effort to try and add it
[15:51] <minimal> plus wouldn't want my changes to make it any harder to add other os support in future
[15:52] <minimal> once I get a PR together then you can test FreeBSD support for me ;-)
[21:38] <blackboxsw> ok one more upstream release published to ubuntu Lunar: [ubuntu/lunar-proposed] cloud-init 22.4.1-0ubuntu1 (Accepted)  thanks falcojr 
[21:39] <blackboxsw> falcojr: plan is to now queue these uploads for ubuntu/kinetic|jammy|focal|bionic. so that when our 22.4 SRU clears the queue, we ping S-R-U release vanguards to assess and approve the 22.4.1 upload containing only the fix https://github.com/canonical/cloud-init/pull/1853
[21:39] -ubottu:#cloud-init- Pull 1853 in canonical/cloud-init "net: skip duplicate mac check for netvsc nic and its VF" [Merged]
[21:40] <falcojr> blackboxsw: so we can just let them sit in approved queue until current SRU clears?
[21:42] <blackboxsw> @falcojr we can do either. let them sit or I can upload once we vet the ubuntu/* branches and we will only ping from S-R-U review once we've cleared solutions QA.  Probably best if we ping/await  solutions QA results on 22.4 before muddying the upload queue to unapproved (B, F, J, K) series
[21:43] <falcojr> I'll see if there's any updates from them, but tomorrow is technically the end of the waiting period
[21:43] <blackboxsw> yeah let's double check. I really don't want to push a release out if solutions QA doesn't have a +1 for us here
[21:44] <blackboxsw> especially given upcoming US-holiday