With content-interface, normally, people need to connect relevant plug and launch the app afterwards.
For a dockerized-app, it will be
$snap connect docker-app:docker-executables docker:docker-executables
And when an application is fired up, the context in which it is run will execute the bind mount so that the bind mount will not take place until the an app startup.
However according to my observation, when it comes to a daemon-based app,
redis-hello-world: command: docker-wrapper docker-compose -f $SNAP/services/redis-hello-world/docker-compose.yml up daemon: simple plugs: [network, docker-executables, docker-cli]
due to the shared folder being not mounted while a daemon runs, it causes daemon fails to run if it relies on sth from producer end to work, even after a reload for docker-app upon the plug connection(Is this considered a bug?).
I took a look at ubuntu-app-platform snap and created a simple daemon-based snap to list the children of shared folders from ubuntu-app-platform for testing purpose. It works and turns that the platform slot is auto-connected upon the daemon snap installation and we don’t need to have a manual connection. So this time a daemon-based app works.
slots: content: allow-auto-connection: - plug-attributes: content: $SLOT(content) slot-attributes: content: ubuntu-app-platform1
It look like an auto-connection interface on producer end is needed in this case so that a consumer snap can get relevant plug connected upon installation and we can have a daemon-baed app running. Do I have this correct?