Kimmo Lehto

That would run k0s on every shell invocation, not a best practice. The usual way is something like: ```shell k0s completion zsh > /usr/local/share/zsh/site-functions/_k0s ```

The current example of doing: ```shell k0s completion zsh > "${fpath[1]}/_k0s" ``` may end up writing the file somewhere weird if you're using some zsh plugin framework, for example on...

You can run k0s controllers and workers simply with `k0s controller` or `k0s worker`. There aren't many arguments and the defaults are ok. Adding a "running without installation" or a...

> This issue seems like a better place to vomit my thoughts Excellent feedback and good points! > As an operator, I want to manage only a single config file...

> Once https://github.com/k0sproject/k0sctl/issues/302 is resolved, is there anything that still needs to be manually configured on each host, or can k0sctl cover everything at that point? If you enable dynamic...

VCR is a waste of time as the client does not care about the responses, it returns raw json. It adds nothing if you write tests that expect the response...

The "process.env" part from #33 was already merged, so in that regard this issue has been solved. I think `process.stdout.write` and `process.stderr.write("foo\n")` should be rather easy to add and there...

Sounds reasonable. Implementing is not a piece of cake, the gzip happens in the depths of [rig's](https://github.com/k0sproject/rig) upload function.

I created a new repo: https://github.com/k8s-ruby/k8s-kubeconfig The library should be fully functional but is missing tests.

The problem here is that if you have something like `KUBECONFIG=~/.kube/foo:~/foofoo`, any references with relative paths will not be remembered and loading them will fail.