Hi folks,
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
Name: clouddiff
Can somebody vote for it?
@reviewers Can someone check this post and reply with any concerns or approval?
Hi @dkazants
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:
ls /home/dkazants/.local/share/juju/cookies/localhost-localhost.json
/home/dkazants/.local/share/juju/cookies/localhost-localhost.json
But locking it requires write permission.
ls /home/dkazants/.local/share/juju/cookies/localhost-localhost.json.lock
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:
dot-local-share-juju:
interface: personal-files
write:
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:
juju-client-observe
- 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
@dkazants hey,
It’s been a while since we last discussed. What’s the status of this request?
Thanks!
Hey @dkazants - ping, could you please provide the status of this request? Thanks.
Hi @emitorino @sahnaseredini , I will update on this issue shortly. Thanks
2 Likes