I’ve created a tool “clouddiff” which is useful for customers with big PCB clouds. It allows to compare two different PCB deployments, or to track changes made within the same site. It also allows to print inventory list of the PCB cloud. As per design it parses juju commands output and returns to the user useful information based on it. Since this tool will have strict confinement it will need an access to juju binary and juju personal-files ($HOME/.local/share/juju) via interfaces “content” and “personal-files” respectively. I would like to ask your approval to auto connect those interfaces during installation.
Publisher: Dmytro Kazantsev
Can somebody vote for it?
@reviewers Can someone check this post and reply with any concerns or approval?
As far as I know, the best way to get access to the juju binary would be to distribute a copy of it within the snap using the
stage-packages instead of using any interface for that.
Regarding the access to
$HOME/.local/share/juju it can be also achieved via the
juju-client-observe interface. In order to grant auto-connection to this interface, I wonder if the snap name should be
juju-clouddiff since as happened with Request: Autoconnect juju-client-observe for cloud-status, this looks to be juju specific, and then the fact that the snap gets access to your local juju config would hopefully not be surprising.
@jslarraz Thank you for these valuable suggestions. I added juju as a stage-snaps and tried to access $HOME/.local/share/juju via juju-client-observe interface but it looks like I get only read permission to this directory and when juju is invoked I get following error:
ERROR opening API connection: cannot load cookies: file locked for too long; giving up: cannot acquire lock: open /home/dkazants/.local/share/juju/cookies/localhost-localhost.json.lock: permission denied
So I believe I need write permission to this directory which juju-client-observe can not provide. Any hints or suggestions to overcome it?
You are right, the juju-client-observe interface only gives read access. However, I would expect it to be enough for juju to run (what is the value of this interface oherwise? hehe).
- Could you please confirm that
/home/dkazants/.local/share/juju/cookies/localhost-localhost.json.lock does not already exists when juju is invoked?
- If that is the case, could you also please confirm that connecting a
personal-files granting write access to
$HOME/.local/share/juju/cookies fixes the issue?
- File localhost-localhost.json exists:
But locking it requires write permission.
ls: cannot access ‘/home/dkazants/.local/share/juju/cookies/localhost-localhost.json.lock’: No such file or directory
- Yes, it was my initial implementation to give write access to this directory via “personal-files” .
Following gives me write access and I can execute juju command:
This seems to be a side effect in juju code which writes something to .local/share/juju directory so effectively any juju command invocation at least in 3.1 need write access to this directory.
@dkazants Thanks for checking:
So, if juju only needs write acccess to lock files placed in
/home/dkazants/.local/share/juju/cookies/, I would suggest to request:
- personal-files write: $HOME/.local/share/juju/cookies
Hopefully, at some point, we will include the write access to the lock files as part of
juju-client-observe (what’s the value of this interface otherwise?) and we could get rid of personal-files here.
I would like to ask you again to consider changing the name of this snap to
juju-clouddiff. In that case, I would certainly support this request for consistency with other existent snaps (i.e. juju-cloud-status ). Otherwise, I would like to hear other @reviewers opinions on this topic
@jslarraz I tried to register new “juju-clouddiff” snap name but it looks like it has been reserved:
" 'juju-clouddiff ’ is reserved. You can request a reserved name or register a new name below."
Maybe the store team (pinging @odysseus-k @lofidevops) can provide some insights on whether it is still possible to register that reserved name
I’ve just realized that this tool needs an access to some other pieces of the system (maas, juju, apt), so just wandering whether I can create this tool with classic confinement?
According to Process for reviewing classic confinement snaps , Classic requests should fall under at least one of the supported categories. Looking at the list I’m not sure in which category would fit this snap.
Regarding the tools required by this snap to run, it should be possible to stage MaaS (just as you did with juju). apt might be more tricky but there might be alternatives depending on what it is required for