After some reflections from my part …
From the last post in derailed store-request it sounds like it is preferred (by @derailed) that k9s is able to access the users kubectl from $PATH. This will of course not work in a strict confinement. This may change in the future with new fancy snapd/portal features. The only way for this to work would be to make it classic.
I found the largest blocker to be the “open this in your $EDITOR” feature that at the moment requires k9s to use classic to function fully. I’m not using that function and I much prefer to use a confined snap over an much less secure classic snap.
@derailed I love to help you with the k9s snap, I think you have three options at the moment:
- Make your case for classic to Canonical (you have a few unanswered questions)
- Wait for snapd to evolve the needed features so everything works in a strict confinement
- Publish the snap with less functionality
Let me know how you like to move on, I guess alternative 2 is what’s going on at the moment. If you like to stick with it I suggest you make the k9s snap private to prevent users from finding and installing the really old and broken version published in the store. Alternative 3 is more or less what I did in k9s-nsg or just remove the e function in the snap.
@jdstrand I feel that there is still a need for k9s-nsg, if the user is fine with the bundled kubectl and vim or nano as an editor, my snap is fully functional. For me and several of my colleges this snap would be a perfect fit. I like to move on with my original request so I can publish the snap.