[02:18] <SuperLag> 🤬
[02:26] <SuperLag> back to where I was before... it validates, but I get the same error as above
[03:04] <holmanb> SuperLag: got a reproducer? more info required to help
[05:12] <SuperLag> holmanb: sorry, had left for a bit. It looks as if the GPG key for the repo gets installed in /etc/apt/trusted.gpg.d, but the repo doesn't end up getting installed, so I must have the repo syntax wrong somehow
[05:12] <SuperLag> source: 'deb [signed-by=$KEYFILE] https://apt.releases.hashicorp.com $RELEASE main'
[05:16] <SuperLag> is $KEYFILE a default var?
[05:21] <SuperLag> I'm trying pointing to the location where the key ended up getting installed. --> [signed-by=/etc/apt/trusted.gpg.d/hashicorpsource.gpg]
[05:21] <SuperLag> might be a chicken egg scenario, but easy experiment
[05:23] <SuperLag> 💥
[17:48] <holmanb> SuperLag: figure it out?
[18:00] <SuperLag> yessir
[18:08] <meena> holmanb: thanks for all the help with that is_virtual pr
[18:09] <holmanb> meena: no problem
[18:10] <meena> I promise the next one will be much worse
[18:11] <holmanb> lol
[18:11] <minimal> I'm working on a is_virtual PR currently for Alpine
[18:12] <meena> minimal: are you using a helper, or doing it from scratch?
[18:13] <minimal> I'm using virt-what
[18:13] <holmanb> minimal: sounds good
[18:14] <meena> what happened to the eatmydata bug?
[18:14] <holmanb> minimal:  at some point we may want to make an openrc mixin if there is stuff that could also be useful for gentoo et al, but that can always be refactored out later
[18:14] <minimal> https://people.redhat.com/~rjones/virt-what/
[18:14] <holmanb> meena: it got filed on LP https://bugs.launchpad.net/cloud-init/+bug/2007400
[18:14] -ubottu:#cloud-init- Launchpad bug 2007400 in cloud-init "eatmydata enabled by default results in apt packages not correctly installed" [Undecided, Incomplete]
[18:15] <minimal> holmanb: not sure. Gentoo seems to the the only distro using OpenRC that I'm aware of. I had a look at their bugtracker for cloud-init issues, not much there. Plus I think it is complicated by Gentoo being a "build it yourself" distro plus it supporting both systemd and OpenRC
[18:16] <meena> and systemd being the default
[18:17] <holmanb> meena: actually openrc is more widely used / default in gentoo
[18:17] <minimal> ah, Arch is OpenRC too, isn't it? and it is supports by c-i
[18:17] <holmanb> minimal: I think that the gentoo distro should maybe be split into two different implementations or something, haven't put that much thought into it
[18:18] <minimal> holmanb: yeah that would make sense
[18:18] <holmanb> minimal: arch is systemd
[18:19] <minimal> holmanb: right, it is officially systemd but OpenRC is also available. Their "arch-boxes" repo is using systemd with cloud-init
[18:19] <holmanb> minimal: huh, TIL
[18:21] <minimal> this is the Gentoo c-i bug list I was looking at: https://bugs.gentoo.org/buglist.cgi?quicksearch=app-emulation%2fcloud-init
[18:22] <minimal> Question: are DataSources checked strictly in the order they are listed? (e.g. in cloud.cfg or the default list)
[18:23] <holmanb> minimal: yes
[18:25] <minimal> ok, I might raise another PR then ;-) Was talking to someone recently who was using/fudging around with ConfigDrive for DigitalOcean....I was surprised as there is a DS for DO's metadata server (added to c-i in 2014) but as ConfigDrive comes before DigitalOcean in list I guess it checks that first (and I assume DO still provide ISO)
[18:26] <minimal> searching online all the DO docs I find about c-i seems to be from around 2018 and only refer to ConfigDrive, found no DO doc referring to their metadata server DS
[18:27] <minimal> plus saw some historical bugs where DO's ConfigDrive files were not fully compatible with OpenStack.
[18:27] <minimal> So thinking of raising a PR to move DigitalOcean before ConfigDrive in default list
[18:30] <holmanb> minimal: Ahh, interesting. Might be  a potential ds-identify issue too, would need to look at the implementation to know
[18:31] <minimal> it's weird DigitalOcean themselves don't seem to publish any docs about using their DS rather than ConfigDrive
[18:31] <holmanb> agreed
[18:34] <minimal> or that they don't stop providing ConfigDrive ISOs so it then skips onto their own DS. I guess they keep that for backward compatibility
[18:34] <SuperLag> holmanb: one weird *cosmetic* issue. No colored bash prompt like normal.
[18:34] <SuperLag> obviously, no big deal... but I wonder why
[18:35] <SuperLag> on first login, it's there. after first reboot, it's gone
[18:51] <minimal> holmanb: re the is_virtual for Alpine, don't hold back 23.1 release waiting for that, I can just patch the change into the Alpine package regardless of whether the (to be submitted) PR makes the release or not
[18:53] <holmanb> +1
[19:16] <minimal> any idea of realistic timescale for 23.1?
[19:32] <meena> minimal: as soon as my horrible patches are done :P
[19:32] <meena> https://github.com/canonical/cloud-init/pull/2003 a week or six
[19:32] -ubottu:#cloud-init- Pull 2003 in canonical/cloud-init "move get_ib_* functions to cloudinit.distros.networking" [Open]
[19:53] <holmanb> SuperLag: sounds out of scope for a cloud-init problem, but it sounds like you should be able to figure out the contents of your shell profile / configs by comparing your environment before and after
[19:55] <holmanb> meena: pr/2003 will probably have to go into 23.2
[19:58] <holmanb> minimal: a couple of cleanup / test fix PRs and getting last minute stuff we want in merged right now, so soon :)