[15:06] <blackboxsw> aciba: per post-standup discussion, I think my initial concern with cc_ssh auto-generation of keys was that our auto-generated key type list didn't include the *-sk key types. In it. I think you confirmed today that these are undesireable for auto-generation because they are secure key or 2factor-auth based and devices and this is not something that makes sense in terms of hostkey generation in early boot.
[15:10] <blackboxsw> aciba: that said, if you ware working on ensuring we have better integration test coverage of auto-generated host keys, it looks like we need to also fix the cloud-init-schema definition of default represented for ssh_genkeytypes as that shouldn't list the `*-sk` values  here https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cloud-init-schema.json#L1912
[15:11] <blackboxsw> the default value there doesn't align w/  https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_ssh.py#L158
[15:16] <aciba> Great thank you, I will include that change. I am also going to ensure that it is possible to import already generated `*-sk` key via `ssh_keys`.
[15:18] <minimal> blackboxsw: would you ever have *-sk *host* keys in any situation? I've assumed *-sk keys would be user keys only
[15:19] <aciba> Related to the next PR, can we drop `squashfuse_in_container` from the config? or are we holding back that kind of breaking changes for a future release?: https://github.com/canonical/cloud-init/pull/1448 
[17:39] <blackboxsw> minimal: True, true, I think you are right. just trying to educate myself on the FIDO-based key types  and it generally looks like it is user-based.  Given as well that `sshkey-gen -A` generates any and all missing hostkey types it also confirms it just creates `ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 ` and not the FIDO types 
[17:46] <blackboxsw> .... and -sk implies a two factor auth device manual interaction too per key use, which doesn't make sense in host context. So, that means cc_ssh.py should probably disallow any -sk type values in `ssh_genkeytypes:` values in cloud-config
[17:48] <blackboxsw> and we should correct our docs and schema for `ssh_genkeytypes` to say ecdsa-sk and ed25519-sk are not allowed values.
[20:14] <holmanb> blackboxsw: autocompletion using config schema is pretty nice :) - I have a minimal working example now
[20:15] <minimal> holmanb: can I have my example back now please ;-)
[20:16] <holmanb> ha! sorry for the ping
[20:16] <holmanb> :)
[20:18] <minimal> I'm used to it, bad choice of nickname on my behalf
[20:19] <holmanb> perhaps, but it is certainly appropriate :)
[20:28] <blackboxsw> haha!
[20:28] <blackboxsw> holmanb: I just got it working in vscode too
[20:28] <blackboxsw> though from the looks of things using it in vscode looks to require that the extension is `.json` but I'm toying with that too
[20:29] <blackboxsw> might be able to provide a min----imal tutorial on getting that setup :)
[20:29] <holmanb> nice :)
[20:30] <falcojr> blackboxsw: which extension?
[20:31] <minimal> blackboxsw: ;-)
[20:32] <holmanb> I'm currently working on a cloud-config that pre-configures an image with nvim for editing user-data with completion, etc
[20:32] <holmanb> so you can boot lxc preconfigured for cloud-config editing
[20:36] <blackboxsw> holmanb: awesome. falcojr: no extension for json editing. one can creat a new  something.json and provide `{ "$schema": "./cloudinit/config/shema-network-config.json", to kick off the intellisence autocompletion magic within that specific file. I'm working on getting the stock YAML/JSON settings.json snippent that'll automatically associate and .yaml or .json file to automatically validate these type of files with our schema
[20:37] <blackboxsw> falcojr: looking at my extensions I only have the following installed: ms-python.python and ms-toolsai.jupyter
[20:37] <blackboxsw> falcojr: I tried using zainchen.json extension but I don't think that was required so I uninstalled it
[20:42] <blackboxsw> sorry I was working on network-config schema right now an copied in the wrong content.   Start a something.json file with `{
[20:42] <blackboxsw>     "$schema": "./cloudinit/config/cloud-init-schema.json",
[20:42] <blackboxsw>     "...
[20:42] <blackboxsw> then each key that someone adds will autocomplete from known valid schema
[20:46] <blackboxsw> https://imgur.com/a/mo4IdKh 
[20:46] <blackboxsw> ^ screenshot of the autocompletion dialog in vscode
[20:46] <blackboxsw> plus imgur ads :/
[20:49] <falcojr> blackboxsw: Ah, gotcha. But this won't actually be super useful for us because our cloud-config is yaml, right? Or that's what you're looking at?
[20:50] <blackboxsw> you can note as well the vscode had a built-in json.schemastore.org lookup for schemas anyway. so it'll try to autocomplete even the $schema urls with known schemastore values
[20:50] <blackboxsw> falcojr: though JSON is a strict subset of YAML
[20:50] <blackboxsw> so it could be provided as #cloud-config.  And if I can sort the file association with *.yaml files I think it'll work there too. But double checking that today
[20:51] <falcojr> blackboxsw or holmanb: would one of you mind taking a look at https://github.com/canonical/cloud-init/pull/1437 soonish? If it's ok, I'd like to get it merged by EOW to make a few more test jobs green
[20:52] <holmanb> can do
[20:52] <blackboxsw> +1 looking now too.
[20:53] <minimal> just working on packaging cloud-init main on Alpine in preparation for 22.2 and seeing multiple growpart tests failing with "fixture 'mocker' not found"
[20:53] <minimal> the output shows a list of available fixtures and mocker is not one of them
[20:53] <holmanb> minimal: that sounds familiar, is mocker in a different alpine package?
[20:53] <falcojr> minimal: we added a test dependency on pytest-mock
[20:53] <blackboxsw> hrm minimal does Alpine not have a pytest-mock?
[20:54] <minimal> ah, its a subpackage, I'll add it to the packaging deps
[20:55] <blackboxsw> minimal: what is a good way for us to announce when test dependencies change that could impact Apline builds/test runs?
[20:57] <blackboxsw> or at least to ensure dependencies added to `test-requirements.txt` don't break
[21:00] <blackboxsw> falcojr: just because I had context on JSON YAML: https://paste.opendev.org/show/bQ2c5KFj7e3FYkvkLFOg/
[21:00] <blackboxsw> Anyhow... right it's not exactly a fit, but it can provide some guidance :/
[21:01] <minimal> blackboxsw: not sure. Until recently the packaging wasn't actually running any tests.
[21:02] <minimal> with that fixed I'm seeing some other test problems with the recent ssh password related changes, seems to be "systemctl" vs "service" calls, I'll have to do some digging
[21:11] <minimal> blackboxsw: so of the 6 test failures I have now, 5 of them are of this form:
[21:11] <minimal> E       AssertionError: [call(['systemctl', 'status', 'ssh'], capture=True)] != [call(['service', 'ssh', 'status'], capture=True)]
[21:11] <blackboxsw> minimal: you might want to refresh to tip of main, we just landed https://github.com/canonical/cloud-init/pull/1449 which should be fixing those mocks
[21:11] <blackboxsw> 2 hours ago
[21:11] <minimal> ah, I pulled about 3 or 4 hours ago lol
[21:12] <blackboxsw> ... we missed the Alpine bus :)
[21:12] <blackboxsw> it was breaking our daily packaging builds too
[21:12] <minimal> blackboxsw: its a very small bus, single seater ;-)
[21:13] <holmanb> one might call the bus "minimal"?
[21:26] <minimal> blackboxsw: that fixed it - no test failures now :-)
[21:44] <blackboxsw> woot! ship it!
[21:49] <holmanb> falcojr: looks like blackboxsw gave the +1, I have one inline question (curious why one of the assertions dropped), but otherwise looks good to me as well 
[21:53] <blackboxsw> holmanb: +1, my assumption there was that we don't need to prevent running on unsupported clouds which don't have instance.console_log implemented. We'll get that pytest.skip raised at test case runtime when unsupported instead of at test discovery timeframe. this comes with a cost as pycloudlib's Azure-instance which doesn't implement console_log will experience wasted time in test case setup instead of at test discovery
[22:22] <holmanb> blackboxsw: I should have been more clear, I was referring to the `assert 1 == console_log.count(msg)` assertion that was dropped
[22:22] <holmanb> that said, my question was answered on github, and the azure console_log() mark change has been reverted the so it's ready to merge imo
[22:33] <blackboxsw> heh, ok YAML of our json schema is straightforward too in vscode https://imgur.com/a/47oODmG   Just needs CTRL+P `ext install  redhat.vscode-yaml` and adding "yaml.schemas": { "cloudinit"/config/schema-cloud-config-v1.json": "*.yaml"} to `settings.json`
[22:35] <blackboxsw> once we pubish to schemastore that becode readily available via "https://json.schemastore.org/cloud-config-schema" so folks won't even need to have cloud-init source checked out
[22:35] <blackboxsw> s/becode/becomes/