Snapd REST API: Expose bind-mount root in tried snaps

snapd
1

snap try can be tremendously useful in a developer’s workflow. However, from the user’s point of view, there’s an awkward disconnect between snapcraft and snapd. As an example:

  1. Developer runs snapcraft prime
  2. Developer runs snap try prime
  3. Developer wants to make some changes, and ends up cleaning the priming area as a result
  4. Developer runs snapcraft prime again
  5. Developer tries to run app, but the tried snap is now broken since the bind-mount created in (2) no longer exists

The only solution is to run snap try prime again.

As part of an overarching drive this cycle to improve the experience of iterating on a snap, we have a proposal up in the snapcraft CLI to not remove the prime directory if it knows the snap is being tried. The method we’re using to determine this is to parse mountinfo looking for our priming area being used as the root. This works, but it feels a bit like a workaround: snapd already knows this snap is being tried, and it already knows the root. If the root was exposed in the REST api as part of the snap info, we could just talk to snapd for this info instead of looking directly at the mounts. Any thoughts on this?

1 Like
2

I think this could be a good idea to have.

However, currently snapd does not have this information! It sets things up and then lets the system (namely systemd) take care of it; it doesn’t keep track of what was mounted, outside of the changes (which are ephemeral). For this to work we’d have to track the path in the snap’s state itself.

I need to chat with other steakholders for this.

1 Like
3

Actually I should just give them a shout here so they read this. Hey @zyga-snapd, @pedronis, what do you think about this?

4

@chipaca isn’t what is asked MountFile() which in this case is a symlink that they can follow? or we follow it (which would leak less implementation details)

5

We know that a snap is in try mode already so I’m not sure what kind of api is needed? Is that some kind of “snap what-is-the-try-directory-of snap-name”?

6

hmm, I think you’re right: snapd can read the MountFile() link and return that.

nah, it’s just to add an entry to the json object returned by /v2/snaps/.

1 Like
7

#5233 adds a "mounted-from" member to local snaps’ JSON. When that snap has "trymode":true, then "mounted-from" will point to the directory being tried (otherwise it points to the squashfs blob).

My suggestion would be not to refrain from removing the prime directory, but to instead remove it from snapd just before removing it and recreating it, and to re-try it after. This way changes to the prime/meta directory (including changes to apps’ commandlines, for example) will be picked up.

In any case, you’ll now have the information to make this kind of decision.

https://github.com/snapcore/snapd/pull/5233

is now on master.

1 Like
8

That’s a good idea, @Chipaca, thank you. And thanks for the fix!