[00:45] <habys> hey folks, when I add a key for a local package repository via the `user-data` file, it adds the key into /etc/trusted.gpg, which breaks attempting to run `apt update`. Has anyone else run into this?
[00:46] <habys> I'm thinking to work around it by putting the keys into /etc/trusted.d/source.gpg manually, but that is a lot more trouble than using the built-in `sources:` section in `user-data`.
[01:32] <holman> habys: How are you adding the key? Could you share a link to your user-data file?
[01:34] <holman> habys: What version of cloud-init are you on? There were some recent feature additions in the apt module around key handling.
[01:52] <habys> interesting, I will copy paste the relevant part in a sec
[01:53] <habys> I was just taking the down time to write a script to pull down new iso, kernel, and initrd for our ipxe environment
[01:53] <habys> I don't know the version of cloud-init, but the installer ISO was from 2022-11-03
[01:54] <habys> ah: /usr/bin/cloud-init 22.3.4-0ubuntu1~22.04.1
[01:58] <habys> here is what I hope is the relevant part of the config, here I am adding our local puppet mirror: https://termbin.com/rgfj
[01:59] <habys> oh heh, that's not local, but the idea is the same.
[02:49] <habys> I found my notes from setting this up manually, I would take the puppet repo key and put it in `/usr/share/keyrings/puppet7.gpg` then refer to it in `/etc/apt/sources.list.d/puppet7.list`: `deb [arch=amd64 signed-by=/usr/share/keyrings/puppet7.gpg] https://apt.puppetlabs.com jammy puppet`
[03:36] <habys> it's pretty late here, so I will probably miss any response. Thank you for looking. I have another question that's killing me.. Every time something isn't perfect in my `user-data` file, I get this crash: https://i.imgur.com/UKBUYIR.png
[03:37] <habys> afaict, there is nothing about what caused the crash on the screen and the listed crash file also does not tell what caused the crash.
[03:38] <habys> for example I can put an intentionally bad command in `late-commands:` but I can not grep for it in these logs. Any help there would really really help me, and help me be more self sufficient.
[03:38] <habys> ty! Good night
[07:12] <meena> habys: autoinstall and cloud-init aren't the same thing
[07:15] <meena> I think you wanna ask #ubuntu-server for help here
[11:04] <habys> I thought cloud-init parses `user-data`?
[11:10] <aciba> habys: the autoinstall key is treated as an opaque config, the only validation cloud-init does is checking that a version subkey is present: https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_ubuntu_autoinstall.py#L135
[11:13] <aciba> habys: the autoinstall config is then handed-over to subiquity
[11:14] <aciba> habys: autoinstall documentation: https://ubuntu.com/server/docs/install/autoinstall
[11:19] <habys> thanks for helping, I'll read this because I am definitely having trouble understanding what the different components are doing
[13:46] <Jack> Hi,
[13:46] <Jack> For file ownership issue, could we need to create a new module to handle it?
[13:46] <Jack> https://bugs.launchpad.net/cloud-init/+bug/1990513/comments/7
[13:46] <Jack> I'd like to hear your advice whether a new module is valuable.
[13:46] -ubottu:#cloud-init- Launchpad bug 1990513 in cloud-init "write_files defer not using ownership for new folders" [High, Triaged]
[13:49] <falcojr> Jack: since we already have the functionality in 'write_files', I think the behavior there could be updated
[13:49] <falcojr> if a directory already exists, don't modify the permissions, but if it doesn't exist, create it with the owner/permissions specified
[13:55] <Jack> Thanks for your suggestion, I'll try to implement it and file a PR for your review
[15:24] <Jack> Hi
[15:24] <Jack> I am trying to Sign the Canonical contributor license agreement.
[15:24] <Jack> What should be filled in 'Please add the Canonical Project Manager or contact'
[15:24] <Jack> It is a required field.
[15:24] <falcojr> you can put James Falcon
[15:25] <Jack> Thanks
[15:25] <Jack> And Launchpad id is username of launchpad, right?
[15:26] <falcojr> yes, that can be left blank if you don't have one
[15:26] <Jack> Got it, thx
[15:37] <minimal> tail g
[15:37] <minimal> oops
[15:37] <minimal> meena: I see you getting a mention: https://www.freebsd.org/status/report-2022-10-2022-12/#_freebsd_as_a_tier_1_cloud_init_platform
[16:04] <meena> minimal: that's not a mention, that's my report 
[16:22] <holman> minimal: any reason you can't can't just mock cloudinit.distros.networking.subp.subp" each each test individually?
[16:24] <holman> minimal: the patch in the shared function goes out of scope when the function ends https://docs.python.org/3/library/unittest.mock.html#unittest.mock.patch
[16:24] <holman> I think meena mentioned that in the PR, maybe that got missed
[16:28] <holman> my gut reaction to that set of tests is that there's a lot of repitition
[16:28] <holman> 150 lines in that test class and it's mostly copy/pasta -> some parametrization could make that a lot more succinct
[16:29] <holman> but obviously you didn't write them that way, don't feel like you have to do that
[16:29] <Jack> Hi guys
[16:29] <Jack> Feel free to review this PR if you have time.
[16:29] <Jack> https://github.com/canonical/cloud-init/pull/1980
[16:29] <Jack> Fix https://bugs.launchpad.net/cloud-init/+bug/1990513
[16:29] -ubottu:#cloud-init- Pull 1980 in canonical/cloud-init "Set ownership for new folders" [Open]
[16:29] -ubottu:#cloud-init- Launchpad bug 1990513 in cloud-init "write_files defer not using ownership for new folders" [High, Triaged]
[16:38] <minimal> holman: I did at first try mocking subp in each test and it didn't work - that was before I decided to move the mock to the _mock_init function
[16:42] <holman> minimal: works for me https://dpaste.org/GPoOp
[16:46] <minimal> I haven't had time this week to update the PR with feedback, I'll be doing that later today
[16:50] <holman> +1 sounds good
=== EugenMayer591 is now known as EugenMayer59
=== EugenMayer599 is now known as EugenMayer59