[01:54] <faa> https://pastebin.com/uJNJcUbC FreeBSD cloud-init 21.4 py38-jsonschema-4.2.1_1 crush, we have more old jsonschema3 this work, it's ok?
[01:56] <faa> cloud.cfg not have default no_ssh_fingerprints: true and disable_network_activation: true, this make warnings in logs
[02:19] <minimal> faa: you can add these when you create your cloud-init enable image
[02:27] <faa> thanks, for now I will probably create a file cloud.cfg.d / 99_freebsd.cfg 
[12:05] <MrGeneral> Hello holmanb, sorted it, turns out the image is perhaps the issue. I downloaded another one and it worked.
[14:02] <holmanb> Mr. General:  Good to hear
[18:15] <blackboxsw> falcojr: minor review comments on your json schema branch, https://github.com/canonical/cloud-init/pull/1144. And generally I think it'd be good to darken our cloudinit code. Outside of this branch, I think if we are trying to apply stylistic and auto-formatting changes to cloudinit codebase,  we want to do it in a single separate PRs which contain no functional changes.
[18:15] <blackboxsw> This allows downstreams to review format-based diffs more easily and separately than multiple PRs that  interleave formatting and functional PRs.
[18:18] <blackboxsw> I really do want to adopt black/isort/darker for cloud-init if we can. And we should announce that intent on the mailing-list just for folks to consume in future dev efforts. New code should probably adopt that black/darker/isort  so we don't have to have any review conversations about different coding style, import order etc.
[18:19] <blackboxsw> I'm guessing you and holmanb are probably in the same boat as I think I've seen PRs from both of you that reference darker :)
[18:19] <blackboxsw> s/in the same boat/of the same opinion/
[18:27] <holmanb> @blackboxsw: I've been using darker as a last step prior to commits, which shouldn't cause any format changes except the lines that already differ from previous commits.
[18:28] <holmanb> @blackboxsw: If using it as an editor save-hook, however, intermediary changes prior to commit get "darkened", which causes non-functional changes to be pulled into the commit, which is the what I think causes  the "non-functional changes" that I think you're saying we want to generally avoid
[18:32] <holmanb> @blackboxsw @falcojr: I'd happily rebase open PRs if it means we can run darken cloud-init and then add black+isort as a travis hook - rebasing should be pretty straightforward -> run changes through black and push change
[18:40] <holmanb> related - pylint takes about 2x the time of integration tests to run (4ishm vs 7ishm, iirc), and it really doesn't catch much that flake8 doesn't catch - I'm curious how much value folks think it adds (particularly curious  people think that halving our "time to green light" would be of more value than the couple of things that only pylint catch)
[18:40] <holmanb> just some musings ^^
[18:53] <blackboxsw> +1 on using pre-commit and darker where we can during ongoing development for the moment. I'm just wondering if it might be better to discuss  a day/time where we generally "darken" or black format + isort all cloudinit modules. Then any subsequent PRs that touch those modules won't start applying non-functional changes to old code in each separate PR that touches a given line.
[18:58] <blackboxsw> holmanb: do I owe you a review on https://github.com/canonical/cloud-init/pull/1130?
[19:08] <holmanb> @blackboxsw: I need to fix something first, not yet
[19:24] <falcojr> blackboxsw: I use darker as my editor formatter, so when I hit save it automatically formats the changed lines. I'm doing it as a personal thing. If we want to enforce something project wide, I think it makes sense to just jump to black with a github action that applies it as a new commit to all incoming PRs. I've held back on pushing black because
[19:24] <falcojr> it can be fairly invasive for open PRs, but maybe now's a good time because there aren't too many open community PRs. I also thought we could start with pycloudlib as a trial run.
[19:26] <blackboxsw> +1 falcojr on pycloudlib too. we already use it by default in ubuntu-advantage-tools to a good benefit. But, black-formatting the world came at an initial cost
[19:28] <blackboxsw> I think this switch in pycloudlib should be trivial and only affect Canonical. Let's bring it up tomorrow at standup and see if we can shift pycloublib to use black+isort. I expect that'd idea get buyin
[19:30] <themachine> When using the Mounts module is there any mechanism to get cloud-init to translate /dev/vdX to it's appropriate UUID?
[19:33] <falcojr> themachine: No, but you're free to specify a UUID using that module
[19:34] <falcojr> holmanb: I don't entirely understand travis times as they're often much shorter than what's reported, but pylint is faster than integration tests 
[19:35] <holmanb> @falcojr: trying to remember how/when i pulled those numbers
[19:35] <holmanb> but if that's the case then nevermind
[19:36] <themachine> falcojr: I may be doing things in a less than desirable way but I don't know the UUIDuntil after everything is done. I'm giving a qemu/kvm a raw .img and using cloud-init's fs_setup to format it as a swap device
[19:37] <themachine> but if that is how it is then oh well, will just have to run commands post setup to add it to fstab
[19:38] <holmanb> oh that may have been integration test times when deb build failed (causing integration tests to exit early)