Comment 7 for bug 1674824

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

There are several things going on:

1. your snap is using this for plugging the ubuntu-app-platform content interface:

plugs:
  shared1:
    content: shared1
    interface: content
    target: shared1
    default-provider: provider1:shared1
  shared2:
    content: shared2
    interface: content
    target: shared2
    default-provider: provider2:shared2

This yaml is using an invalid name for 'default-provider', is specifying a non-existent 'content' value and does not ship /run/consumer/current/shared1 or shared2. See https://github.com/snapcore/snapd/wiki/Interfaces#content for how these interface attributes are to be used.

Since the ubuntu-app-platform has this in its yaml:

slots:
  platform:
    content: ubuntu-app-platform1
    interface: content
    read:
    - .

your snapcraft.yaml should be something like for the ubuntu-app-platform snap:
plugs:
  uap1:
    content: ubuntu-app-platform1
    default-provider: ubuntu-app-platform
    target: shared1

where 'content' is the same as the 'content' value in the providing snap (ie, ubuntu-app-platform1), 'default-provider' is the name of the providing snap (ie, ubuntu-app-platform) and 'target' is the name of a directory in $SNAP for you snap (this directory *must* exist because it cannot be created for you).

2. 'sudo snap install ./consumer*snap --dangerous' results in autoconnecting ubuntu-app-platfrom despite all of the above issues with your snap.yaml. This is because of a too-lenient snap declaration.

3. Because of the too lenient snap declaration for ubuntu-app-platform, if you have a snap that plugs both ubuntu-app-platform and mir-libs, since mir-libs does not currently have a snap declaration, both plugs would be auto-connected to ubuntu-app-platform and mir-libs skipped.

Note that local unasserted snap installs of content snaps don't have a signed snap declaration on the system, so only the base declaration can be consulted. This accounts for differences in behavior with snaps installed with and without --dangerous.

I have adjusted the snap declaration for ubuntu-app-platform to have:

slots:
  content:
    allow-auto-connection:
      -
        plug-attributes:
          content: $SLOT(content)
        slot-attributes:
          content: ubuntu-app-platform1

This means that the auto-connection can only happen with the plugging snap that uses "content: ubuntu-app-platform1", which is precisely how it is supposed to work.

To fix your snap for ubuntu-app-platform and mir-libs, use this yaml:

plugs:
  uap1:
    interface: content
    content: ubuntu-app-platform1
    target: shared1
    default-provider: ubuntu-app-platform
  ml0:
    interface: content
    content: mir0
    target: shared2
    default-provider: mir-libs

then create the shared1 and shared2 directories beside your snapcraft.yaml file, then snapcraft will generate a snap that will work for you. Specifically, if you install ubuntu-app-platform first, upon install of your snap ubuntu-app-platform will be mounted on $SNAP/shared1 and nothing will be mounted on $SNAP/shared2 (since mir-libs doesn't yet have a snap declaration for auto-connection). When you 'sudo snap connect consumer:ml0 mir-libs:mir-libs', then mir-libs will be mounted on $SNAP/shared2 (after you first 'sudo /usr/lib/snapd/snap-discard-ns consumer').

In summary, there is no bug in snapd, but there are bugs in your snapcraft.yaml and there was a bug in the ubuntu-app-platform's snap declaration. Since the snap declaration is now fixed, marking Fixed Released.