For our workloads on ubuntu core, I was thinking of having different snaps for different jobs, but I need a way for them to share a small information somehow. So,
snap a would do some work and publish the result of that work, and make it available to query by
snap b and
I was naively hoping that I could use snapctl set/get perhaps, but of course the snap don’t have access to anything other than their own context for that.
Is there a recommended approach to problems like this ?
Maybe using the
You could use the content interface and share a unix socket this way, or just simple file locks, etc.
Perhaps content interface is the way to go here.
I would still then have to come up with a good way of storing and sharing some data. The simplest way would be just a well defined fs structure within the source content snap.
It is a shame there is no equivalent interface or way of exposing snap config, read only, to some other snaps. Just being able to do arbitrary
snapctl set/get is really nice, and available within all snaps.
I guess we could implement another key value store in the source content snap, but then we would have to abstract the access to it in every snap that required it.
Well if you have a brand store your snaps can use snapd-control to set and get config values for any snap, but admittedly snapd-control is a very very powerful interface for just what you describe. We are looking at eventually splitting up snapd-control to subsets that are less powerful and can be granted more permissively, so perhaps splitting off reading config but not writing it would be one such interface.
We are just in the process of getting a brand store now [ should be getting it any day now ].
@ijohnson Having a version of
snapd-control that was read only, or taking it a step further and having a filter parameter to control what can been see would be really great.
Do you have anywhere to track the splitting of
snapd-control interface work ? Would it help prioritise if a commercial customer requests it ?