I would like to explain why kube-commander snap needs classic confinement.
kube-commander is a terminal user interface utility which works directly with kubernetes CLI kubectl. Which means it needs access to both $HOME/.kube and kubectl executable. As I understand, providing access to $HOME/.kube is possible with personal-files plug, but accessing host executables is not allowed using strict confinement.
All kube-commander versions that currently published use strict confinement and they just don’t work.
Currently I tried to publish version 0.2.1 with classic confinement and got this message from snapcraft:
Will need manual review…
The Store automatic review failed.
A human will soon review your snap, but if you can’t wait please write in the snapcraft forum asking for the manual review explicitly.
Can you provide more details for “they just don’t work”? There are a variety of kubernetes snaps in the store, some that work in strict and some that are classic. We’ve identified that “kubernetes tools requiring arbitrary authentication agents” as one use case for classic-- is the trouble your seeing in reference to authentication agents or something else?
kube-commander needs multiple things to run properly:
Access to user’s ~/.kube/config
Ability to run external binaries in user-space: kubectl, configurable pager (less), configurable editor (nano or vi)
I was considering packaging binaries with kube-commander, but it will lack configurability - user will be forced to use packaged editor and pager.
The whole point of kube-commander is to work as easy as kubectl works. It uses user’s kubectl configuration which is usually present when user works with Kubernetes clusters.
Access to ~/.kube/config can be achieved via an appropriate personal-files plug declaration.
Could you ship kubectl within kube-commander?
Users do not generally configure their pager, but nonetheless you could still ship various pagers if you desired (however 99% would still use less so I would think shipping just this would be enough).
Finally, can you elaborate more on the use-case of editing? Would it be possible to launch the editor via say xdg-open /path/to/file/to/edit - combined with say XDG desktop portals this could allow a user to choose the editor as needed.
When I was reading documentation about plugs and interfaces a while back it felt a little confusing so I got lost in the process of configuring it. I will give it another go.
Shipping kube-commander with kubectl is possible, but it felt too unnecessary at the moment.
Editing is usually done in the terminal with nano or vim, but xdg-open actually could help with some complicated YAML edits. kubectl edit is using EDITOR var and kube-commander just calls kubectl edit which then calls $EDITOR <temp_file>. I suppose that setting EDITOR to xdg-open should do the trick in this case.
I feel that this thread is resolved, thank you for the help
