| === bahamat_ is now known as bahamat | ||
| 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:06 |
|---|---|---|
| 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:10 |
| blackboxsw | the default value there doesn't align w/ https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_ssh.py#L158 | 15:11 |
| 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:16 |
| minimal | blackboxsw: would you ever have *-sk *host* keys in any situation? I've assumed *-sk keys would be user keys only | 15:18 |
| 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 | 15:19 |
| ubottu | Pull 1448 in canonical/cloud-init "Drop cc_snap.maybe_install_squashfuse." [Open] | 15:19 |
| 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:39 |
| 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:46 |
| blackboxsw | and we should correct our docs and schema for `ssh_genkeytypes` to say ecdsa-sk and ed25519-sk are not allowed values. | 17:48 |
| holmanb | blackboxsw: autocompletion using config schema is pretty nice :) - I have a minimal working example now | 20:14 |
| minimal | holmanb: can I have my example back now please ;-) | 20:15 |
| holmanb | ha! sorry for the ping | 20:16 |
| holmanb | :) | 20:16 |
| minimal | I'm used to it, bad choice of nickname on my behalf | 20:18 |
| holmanb | perhaps, but it is certainly appropriate :) | 20:19 |
| 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:28 |
| blackboxsw | might be able to provide a min----imal tutorial on getting that setup :) | 20:29 |
| holmanb | nice :) | 20:29 |
| falcojr | blackboxsw: which extension? | 20:30 |
| minimal | blackboxsw: ;-) | 20:31 |
| 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:32 |
| 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:36 |
| 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:37 |
| 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:42 |
| blackboxsw | https://imgur.com/a/mo4IdKh | 20:46 |
| blackboxsw | ^ screenshot of the autocompletion dialog in vscode | 20:46 |
| blackboxsw | plus imgur ads :/ | 20:46 |
| 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:49 |
| 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:50 |
| 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:51 |
| ubottu | Pull 1437 in canonical/cloud-init "testing: Fix console_log tests (SC-992)" [Open] | 20:51 |
| holmanb | can do | 20:52 |
| blackboxsw | +1 looking now too. | 20:52 |
| 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:53 |
| minimal | ah, its a subpackage, I'll add it to the packaging deps | 20:54 |
| blackboxsw | minimal: what is a good way for us to announce when test dependencies change that could impact Apline builds/test runs? | 20:55 |
| blackboxsw | or at least to ensure dependencies added to `test-requirements.txt` don't break | 20:57 |
| 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:00 |
| minimal | blackboxsw: not sure. Until recently the packaging wasn't actually running any tests. | 21:01 |
| 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:02 |
| 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 |
| ubottu | Pull 1449 in canonical/cloud-init "testing: mock uses_systemd in ssh password tests (SC-1040)" [Merged] | 21:11 |
| blackboxsw | 2 hours ago | 21:11 |
| minimal | ah, I pulled about 3 or 4 hours ago lol | 21:11 |
| 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:12 |
| holmanb | one might call the bus "minimal"? | 21:13 |
| minimal | blackboxsw: that fixed it - no test failures now :-) | 21:26 |
| blackboxsw | woot! ship it! | 21:44 |
| 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:49 |
| 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 | 21:53 |
| 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:22 |
| 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:33 |
| 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/ | 22:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!