Hi,
I need approval to publish the ‘jhack’ snap with classic confinement.
Reason for that is, some of the scripts the snap contains need access to a juju executable which could be anywhere in the user’s system.
I’ve heard I could do something like embed the juju client into your snap, and then add the juju-client-observe plug, but right now I don’t have the time to.
Maybe one day I will, if this grows.
For now, can we release it as-is?
Unfortunately both “difficulty making strict confinement work” and “ability to run other snaps directly (as opposed to defined interfaces)” are both stated as unsupported use-cases for classic confinement at Process for reviewing classic confinement snaps - as such it jhack does not meet the requirements for classic confinement. Other snaps have successfully embedded the juju snap as you suggest so this is the best way forward for your snap at this time.
Right! Thanks for the clarification. Maybe someday…
How do I ‘undo’ the blocked releases? I see a promote/close button in the releases tab, and I was hoping to close the two releases that are stuck awaiting for approval (that ain’t coming), but I only see options to release in the dropdown, which won’t do anything if clicked.
Will try from cli now
Hi @ppasotti,
I see jhack properly released under strict confinement so I am removing this request from our review queue. Feel free to write here again if you have any further question and we will be happy to assist.
Thanks!
Hi all, so contrary to what @emitorino said previously, jhack has only now a strictly confined revision queued for revision (managed to get it working today)
speaking of, that requires manual review because of the personal-files slots I’m using (copied them over from the juju snap).
Do I need to request that here?
Yes for personal-files we will need a forum request - but we can reuse this one.
Can you please provide details for the various personal-files instances that are being requested for jhack and why these are required? Thanks.
Jhack is meant to wrap the juju client. If the juju snap had a slot exposing access to its client binary, I would use that, but it doesn’t, so I had to embed in jhack my own juju snap. The goal is then to make the embedded juju snap behave as if it were the ‘outer’ juju snap.
The juju-client-observe slot is not enough, because it provides read access only and the juju client requires write access to that directory (to write some locks and keep some state), hence the dot-local-share-juju instance.
Next, it is my understanding that:
config-lxd instance is required (to my understanding) to pass lxd config to the juju client.dot-kubernetes instance is required to make the juju snap see the locally available k8s config. In particular, if I locally have a microk8s snap, unless I give the kube config to the embedded juju instance, it won’t be able to see or talk to the locally available k8s controllers.Never mind, I just unplugged config-lxd and dot-kubernetes and things seem to work as they should.
Just pushed a new version only including dot-local-share-juju.
By the way, I wrote down the results of this adventure in a post on charmhub https://discourse.charmhub.io/t/how-to-wrap-the-juju-client-in-a-strictly-confined-snap/6947 would it be better to post it here perhaps?
Hi,
I think it’s a nice workaround. Also amazing that you actually try to snap this, kudos.
An important side effect of your trick is that it now uses your snapped juju version. This can be an advantage because you will always be compatible with juju, by definition. However, the first bug report you’re gonna get is “why doesn’t the jhack use my juju version. I’ve got stuff that only works with Juju XX” If you still allow people to forward their own juju binary, that would counter that issue.
Thanks for your effort.
Kind regards,
Brecht
Thanks @BrechtNr! Something I was also wondering about re juju compatibility is: If I try to use this snap to interact with a juju 2 model/controller, things will break, right? Do I need to create a new track where instead of juju3, I snap juju2?
And one more question for whoever is listening: write access entails read access, I presume, so the dot-local-share-juju plug makes juju-client-observe redundant, right?
Yes
I can’t see the details of your dot-local-share-juju plug, but the rule in the juju-client-observe interface is:
owner @{HOME}/.local/share/juju/{,**} r,
So assuming you’ve requested $HOME/.local/share/juju - then you’ve effectively superseded the juju-client-observe interface and it would be prudent to remove it.
done! thanks for the tip