[13:41] <holmanb> @blackboxsw: ansible config module PR and LXD integration test PRs are up and ready for re-review when you get a chance.
[14:33] <minimal> holmanb: no alpine does not have systemd-detect-virt as it has no systemd at all
[15:17] <holmanb> minimal: yeah, figured
=== themachine is now known as th3machine
[16:02] <minimal> holmanb: there was an attempt to package systemd for Alpine a few months ago but it didn't happen - partly because at least one person perceived that the packager was doing so in order to cause "mischief" but also as quite a few patches were required to get systemd working on musl (the C library Alpine uses) and there was basically zero chance of those patches being accepted upstream (and so such an Alpine package would present a ongoing maintenance 
[16:02] <minimal> issue)
[16:35] <holmanb> minimal: I'm not trying to make init system decisions for alpine or any other distro, but this is a tool that I suspect would probably work standalone without systemd as your init system - it just evaluates what kind of container/vm it's running in based on information available.
[16:36] <holmanb> minimal: the relevent code chunk, in case you're interested: https://github.com/canonical/cloud-init/blob/fe3a2fbfc85dded8d54ef75a5373272743e51378/cloudinit/sources/DataSourceLXD.py#L56
[16:44] <minimal> holmanb: the systemd-detect-virt code is part of the systemd codebase, which is designed to work with glibc so it is likely it requires/assumes glibc extensions
[16:50] <minimal> holmanb: Alpine does have virt-what packaged which is similar, those perhaps not as extensive
[16:52] <minimal> https://people.redhat.com/~rjones/virt-what/
[17:03] <holmanb> ahh, good point, forgot about musl
[17:04] <minimal> holmanb: that's the whole issue of the musl + systemd "standoff", musl is a POSIX-compliant libc, systemd only supports glibc (or glibc compatible) libc
[17:05] <minimal> so attempts to submit systemd MRs to support musl get a "no, tell musl to fix it" whereas musl would say "there's nothing to fix, that's not POSIX"
[17:06] <minimal> anyway, from a quick look at that cloud-init code I'd expect you could easily use virt-what (which is not Alpine-specific) if systemd-detect-virt is not installed
[18:04] <holmanb> minimal: agreed, it looks like it would work based on the man page
[18:05] <holmanb> @blackboxsw: doc8 release looks to be causing CI failures - I have a PR up that should fix it if you get a chance for a quick unblock
[18:07] <holmanb> @blackboxsw: integration tests aren't done yet but I expect to pass, the doc test (the one that fails with unpinned doc8) succeeded with the PR so I think it should get CI back in order: https://github.com/canonical/cloud-init/pull/1621
[18:10] <blackboxsw> holmanb: will grab that now thanks. almost done on your LXD PR
[18:32] <holmanb> blackboxsw: +1 digging into this it looks like this probably wouldn't be a problem except for a different pin we have for sphinx_rtd_theme. With a modern docutils we would be good. I'm going to update the PR to include that info.
[18:52] <blackboxsw> funny to see the primary maintainer of doc8 https://pypi.org/project/doc8/. familiar faces :)
[18:54] <blackboxsw> merged
[19:21] <holmanb> Heh, nice. Thanks!
[19:35] <blackboxsw> holmanb: lvm integration tests look pretty good. sent back a request for how we are working around the lack of dm-thin-pools, otherwise +1
[20:07] <holmanb> @blackboxsw: Thanks for the feedback. cc_lxd only supports ubuntu, which is why I didn't worry about an all-distro solution, but I can add this in case we want to extend support to the other linux distros.
[20:10] <blackboxsw> ahh right-o missed that distros declaration. and given that we probably don't need the   `cloud.distro.name == "ubuntu"`
[20:11] <blackboxsw> +1 on at least making it possible to open this up for more than ubuntu (not in this PR though)
[20:14] <blackboxsw> also, not sure in a followup PR if we also want to take special account for container based storage_backend:btrfs  as it ultimately requires that the underlying host is running btrfs https://linuxcontainers.org/lxd/docs/master/reference/storage_btrfs/#btrfs-driver-in-lxd
[20:16] <blackboxsw> holmanb: otherwise I think we hit the following error  from `lxd init --auto --storage-backend=btrfs`
[20:16] <blackboxsw> `Error: The requested backend 'btrfs' isn't available on your system (missing tools)`
[20:17] <holmanb> good point, the == "ubuntu" was probably misleading for review
[20:24] <holmanb> blackboxsw: interesting point on btrfs, I agree. That's why I excluded the integration tests from lxd, funny enough I didn't think about the implications for the config module itself. Modifying filesystems and volumes from an unpriv'd container shouldn't work (applies to lvm and zfs too).
[20:25] <holmanb> I'll add a fix for that as well to the PR
[20:48] <holmanb> ignore my statement about lvm/zfs/btrfs -> reading the docs it's more nuanced than I assumed due to the lxd user/group
[20:49] <blackboxsw> holmanb: if we get this lxd PR landed today. I'm game for trying to publish an interim release into kinetic which should help Azure folks out on their daily integration tests in kinetic
[20:49] <holmanb> soundfs good to me
[20:49] <blackboxsw> the LXD PR won't help azure out, but the fact that we landed some cc_set_password fixes will
[20:50] <blackboxsw> and I want to start getting LXD stuff out in release streams for better testing and vibislity
[20:50] <blackboxsw> *visibility
[21:00] <holmanb> @blackboxsw: sounds good - there's a small LXD bridge/mtu PR out there too if we want to air that out in kinetic, but no need to shoehorn that into the review queue ahead of the interim release. We need to draw the line somewhere :)
[21:02] <holmanb> @blackboxsw: pushed the storage requested change, CI is running -> https://github.com/canonical/cloud-init/pull/1602
[21:03]  * holmanb will stop broadcasting thoughts at everyone in irc now
[21:18] <blackboxsw> holmanb: thanks for the broadcast. appreciated. I was looking into whether we want to support installing ansible-core as a minimal option/override instead just defaulting to ansible I think we need to check in with athos who is working the ansible server support as I also discovered ansible-core doesn't install without postinst errors on kinetic
[21:24] <blackboxsw> I may have hit https://bugs.launchpad.net/ubuntu/+source/ansible-core/+bug/1969917
[21:24] <ubottu> Launchpad bug 1969917 in ansible-core (Ubuntu) "package ansible-core 2.12.0-1 failed to install/upgrade: installed ansible-core package post-installation script subprocess returned error exit status 1" [Undecided, Confirmed]
[21:25] <holmanb> good idea with -core - A simple way to implement that might be to have the package name as another field (default "ansible", or whatever) the user could then override with -core if they wish
[21:28] <blackboxsw> +1 holmanb that's the comment I have yet to submit
[21:28] <blackboxsw> https://github.com/canonical/cloud-init/pull/1579/files#r931596999
[21:28] <ubottu> Pull 1579 in canonical/cloud-init "Add Ansible Config Module" [Open]
[21:28] <blackboxsw> I think it's reasonable/flexible enough  to allow pip version overrides too
[21:38] <blackboxsw> holman here's the symptom w/ ansible-core on jammy https://bugs.launchpad.net/ubuntu/+source/ansible-core/+bug/1969917/comments/5
[21:38] <ubottu> Launchpad bug 1969917 in ansible-core (Ubuntu) "package ansible-core 2.12.0-1 failed to install/upgrade: installed ansible-core package post-installation script subprocess returned error exit status 1" [Undecided, Confirmed]
[21:50] <holmanb> blackboxsw: nice report! Have you already pinged athos? if not I will
[23:28] <blackboxsw> holmanb: I pinged athos in #ubuntu-server for tomorrow
[23:28] <blackboxsw> https://github.com/canonical/cloud-init/pull/1620 merged
[23:28] <ubottu> Pull 1620 in canonical/cloud-init "LXD Add MTU Support" [Merged]
[23:29]  * blackboxsw wants a bot to announce github PRs merged. It gives such a sense of accomplishment
[23:29] <blackboxsw> ... but maybe that just translates to noise for folks.... opinions welcome
[23:29] <blackboxsw> I guess noisy bots can be muted individually in IRC for those that don't want to look