[11:45] <andras-kovacs> Is that a good assumption the CA Certs module can work on ubuntu and debian only?
[13:50] <Odd_Bloke> andras-kovacs: I believe it depends on tooling that is only present in Debian derivatives, yes.
[14:13]  * andras-kovacs sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/AuwhMuZRuZyPzlqOuLWFhGUG >
[14:13]  * andras-kovacs sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/YqvjIFpIhuWgYdZbGgNSEieo >
[14:14] <andras-kovacs> hmm maybe it's time for me to try to contribute to this project
[14:48] <Odd_Bloke> andras-kovacs: Contributions would certainly be welcome!
[15:03] <apollo13> hi there, can anyone tell me what the diff between nocloud, genericcloud and generic in https://cloud.debian.org/images/cloud/buster/20200210-166/ is?
[15:06] <apollo13> ah found it here: https://salsa.debian.org/noahm/debian-cloud-images/blob/master/README.md
[17:30] <ananke> does the proxy directive in apt module support yum?
[17:30] <ananke> I guess I could try and see
[17:30] <ananke> actually, it appears it doesn't. dang
[17:31] <Odd_Bloke> ananke: It would be surprising if anything in the apt module supported yum. :)
[17:34] <ananke> Odd_Bloke: well, I was going by the notion that apt_update and apt_upgrade are aliases
[17:36] <ananke> and there is no other module that deals with package manager options. hmm, not sure if i'll be able to use 'packages' module then, without being able to set a proxy first
[17:36] <ananke> runcmd runs afterwards
[17:36] <powersj> ananke, there is a yum module
[17:36] <Odd_Bloke> Yep, they're aliases, but in cc_package_update_upgrade_install which is generic.
[17:36] <Odd_Bloke> Looks like the yum module only adds extra repos, rather than allowing config like proxy to be applied.
[17:37] <ananke> powersj: there appears only yum_repos, is that what you're referring to?
[17:37] <Odd_Bloke> ananke: Would a bootcmd work for you?
[17:37] <Odd_Bloke> (It's runcmd but earlier.)
[17:37] <ananke> Odd_Bloke: potentially, that's a good idea
[17:38] <ananke> would you happen to know if write_files is before packages or afterwards?
[17:38]  * ananke should just look at a sample failed host
[17:38] <Odd_Bloke> Check /etc/cloud/cloud.cfg to see the configured order.
[17:39] <Odd_Bloke> (Alternatively, run https://github.com/canonical/cloud-init/blob/master/config/cloud.cfg.tmpl through your brain's Jinja2 parser. :)
[17:40] <ananke> our AMI build environment is behind a squid proxy, which makes a lot of things like that challenging
[17:43] <ananke> ahh, good, write-files is much earlier. it's at the beginning of cloud_init_modules, while package-update-upgrade-install is towards the end of cloud_config_modules
[18:05] <ananke> yay, that worked. sadly yum doesn't appear to support dropping in a file, so I have to change existing /etc/yum.conf
[18:50] <ananke> on that subject, does write_files 'path' directive create missing dirs?
[19:33] <rharper> Odd_Bloke: the cla check says:
[19:33] <rharper> 3s
[19:33] <rharper> We are currently unable to download the log. Please try again later.    -- what does that mean ?
[19:34] <rharper> ananke: yes, it effictively runs "mkdir -p $(basename file)"
[19:34] <rharper> ananke: it also has an append mode
[19:37] <ananke> rharper: thanks! appears to be working like a charm
[19:38] <ananke> had to create a systemd environment file for docker, so it can use proxy
[19:40] <Odd_Bloke> rharper: No idea!
[19:41] <rharper> ananke: nice trick!
[19:41] <rharper> Odd_Bloke: did we already land something from garlof ?
[19:42] <rharper> I was looking at the mime-data type bug and updated that with a fix, but noticed the cla check had a weird result
[19:42] <rharper> I "reran" the checks bit it stayed the same
[19:43] <ananke> rharper: that appears to be the sanctioned method. here's how the net result looks like with cloud-init: http://dpaste.com/3D3B7XC
[19:57] <rharper> cool
[19:58] <Odd_Bloke> rharper: I see a couple of commits from Kurt Garloff.
[20:20] <rharper> Odd_Bloke: ok, I thought I remembered that.    So I wonder what to do with the check failing though;  we have time, waiting for garlof to respond
[20:29] <Odd_Bloke> rharper: So the process is (correctly) failing on one of the PRs because we don't have garloff in our in-repo lists of CLA signers.
[20:29] <Odd_Bloke> (I don't know why it's failing to check out on the other.)
[20:31] <Odd_Bloke> But regardless, I think you'll need to email them on their CLA-signing email address asking them to confirm that they control the GH account in question.
[20:32] <rharper> Odd_Bloke: ok
[20:33] <Odd_Bloke> (And then update the in-repo metadata, of course.)