☁️ CLI & TUI with a smol friendly vibe to get started with Kubernetes on metal, then bootstrap apps using Argo CD 🧸 Great for testing webapps and benchmarking.
Update textual to 0.65, closes #252
updates cryptography to 42.0.8, closes #251
Fixes
There was an error where, if you deleted everything in your ~/.cache/smol-k8s-lab dir and you were using k3s or k3d, then you tried to use the TUI, it would cause smol-k8s-lab to hang.
In this case, since I deleted the k3s.yaml from the cache directory, and then rebooted the node, k3s couldn't start up, which is why the TUI was hung, because it couldn't verify the existing servers in the $KUBECONFIG.
Normally, when the TUI fails, I tell users to please try the CLI and tell me if that works. This also failed, because we were still checking for sensitive values in the env_config stage of the smol-k8s-lab. That function is so old, that it was before I knew about the .get(some_value, some_default_value) method of getting stuff out of a python dict, meaning, for nextcloud/matrix/mastodon, it was still trying to get the sensitive_values key out of the init dict for those apps. I've updated it to have a default value of None, allowing the function to gracefully end. The only reason I kept it there still is that it allows backwards compatibility with older versions of smol-k8s-lab, from before we switched to the value_from method.
Anyway, after I fixed this sensitive value issue, then I was able to run the CLI as normal, which regenerated the k3s.yaml and started k3s again :) All is well.
Updates
Update textual to
0.65, closes #252 updates cryptography to42.0.8, closes #251Fixes
There was an error where, if you deleted everything in your
~/.cache/smol-k8s-labdir and you were using k3s or k3d, then you tried to use the TUI, it would cause smol-k8s-lab to hang.In this case, since I deleted the
k3s.yamlfrom the cache directory, and then rebooted the node, k3s couldn't start up, which is why the TUI was hung, because it couldn't verify the existing servers in the$KUBECONFIG.Normally, when the TUI fails, I tell users to please try the CLI and tell me if that works. This also failed, because we were still checking for sensitive values in the env_config stage of the smol-k8s-lab. That function is so old, that it was before I knew about the
.get(some_value, some_default_value)method of getting stuff out of a python dict, meaning, for nextcloud/matrix/mastodon, it was still trying to get thesensitive_valueskey out of theinitdict for those apps. I've updated it to have a default value of None, allowing the function to gracefully end. The only reason I kept it there still is that it allows backwards compatibility with older versions of smol-k8s-lab, from before we switched to thevalue_frommethod.Anyway, after I fixed this sensitive value issue, then I was able to run the CLI as normal, which regenerated the
k3s.yamland started k3s again :) All is well.