optionally start daemon only if all interfaces are connected

[Jamie Strandboge]

I was asked to file this bug on behalf of a user based on IRC discussion (this is rather long but trying to capture the context and considerations for kyrofa or other implementers/designers).

Consider a router snap that has:

apps:
  foo:
    daemon: simple
    plugs: [ network-control, firewall-control ]

On install the resulting systemd unit will try to restart over and over. What would be great is if the developer had a way to say "don't bother starting me unless all my interfaces are connected" (or change the default behavior).

Once interface hooks are implemented, then snap developer could program this with something like:

* meta/hooks/firewall-control-connect - when connected modifies SNAP_DATA/config to have FIREWALL_CONTROL_CONNECTED=yes
* meta/hooks/network-control-connect - when connected modifies SNAP_DATA/config to have NETWORK_CONTROL_CONNECTED=yes
* command: bin/foo does 'source SNAP_DATA/config ; if [ "$FIREWALL_CONTROL_CONNECTED" = "yes" ] && [ "$NETWORK_CONTROL_CONNECTED" = "yes ]; then start ; else exit ; fi

However, perhaps it makes sense to express this in the yaml so developers don't have to do that.

A naive implementation would adjust the yaml to be:

apps:
  foo:
    daemon: simple
    plugs: [ network-control, firewall-control ]
    restart-condition: on-interface-connect

This doesn't work well since restart-condition has many other options that the user may want (eg, 'on-interface-connect' along with 'on-abort').

An alternative might be ('start-only-when-connected' and 'stop-whenever-disconnected' should obviously be changed to something better! :) :

apps:
  foo:
    daemon: ...
    plugs: [ network-control, firewall-control ]
    restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
    start-only-when-connected: true (default)|false
    stop-whenever-disconnected: true (default)|false

With that we change the default behavior to not start unless all the interfaces are connected and to stop when any interfaces are disconnected, but letting the developer choose to opt out. The problem with this default is that the user loses the ability to have a voice on say, removing 'firewall-control' from the snap but still being able to use the snap. However, we could retain the current behavior (ie, user control by default with snap developer opt in) with:

apps:
  foo:
    daemon: ...
    plugs: [ network-control, firewall-control ]
    restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
    start-only-when-connected: true|false (default)
    stop-whenever-disconnected: true|false (default)

I'm sure there are other options but perhaps the above will spark conversation and ideas on how interfaces connections might influence start and stop behavior.

[Gustavo Niemeyer (niemeyer)]

The current plan is to support this via a "ready" or "wait-for" (name TBD) expression which may AND together a few factors, including whether particular slots and plugs are connected or not.

This might be defined both at a global level, which would prevent the snap from being available at all before the expression is satisfied, and perhaps also at a daemon level, preventing only that particular daemon from going live.

The global expression should be introspected by the system so that the user is told what the given snap is waiting for in a clear way.

[Zygmunt Krynicki (zyga)]

I'm marking this as triaged as it is both defined and has a priority.