| 2016-08-17 15:01:07 |
Jamie Strandboge |
bug |
|
|
added bug |
| 2016-08-17 15:01:41 |
Jamie Strandboge |
description |
I was asked to file this bug on behalf of a user based on IRC discussion (this is rather long but trying to capture for kyrofa or other implementers/designers the considerations).
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 we declared in the yaml 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 do 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:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: true|false (default)
stop-when-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. The problem with this approach 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.
Perhaps something like this:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: yes|no|user (default)
stop-when-disconnected: yes|no|user (default)
Where 'user' (please change this!) is the current behavior. In this manner, the default is the current situation where the user has some say, but the developer can express "don't even bother running if everything isn't connected".
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. |
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 we declared in the yaml 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 do 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:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: true|false (default)
stop-when-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. The problem with this approach 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.
Perhaps something like this:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: yes|no|user (default)
stop-when-disconnected: yes|no|user (default)
Where 'user' (please change this!) is the current behavior. In this manner, the default is the current situation where the user has some say, but the developer can express "don't even bother running if everything isn't connected".
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. |
|
| 2016-08-17 15:02:12 |
Jamie Strandboge |
description |
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 we declared in the yaml 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 do 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:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: true|false (default)
stop-when-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. The problem with this approach 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.
Perhaps something like this:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: yes|no|user (default)
stop-when-disconnected: yes|no|user (default)
Where 'user' (please change this!) is the current behavior. In this manner, the default is the current situation where the user has some say, but the developer can express "don't even bother running if everything isn't connected".
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. |
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 do 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:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: true|false (default)
stop-when-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. The problem with this approach 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.
Perhaps something like this:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: yes|no|user (default)
stop-when-disconnected: yes|no|user (default)
Where 'user' (please change this!) is the current behavior. In this manner, the default is the current situation where the user has some say, but the developer can express "don't even bother running if everything isn't connected".
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. |
|
| 2016-08-17 15:02:30 |
Jamie Strandboge |
description |
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 do 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:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: true|false (default)
stop-when-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. The problem with this approach 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.
Perhaps something like this:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: yes|no|user (default)
stop-when-disconnected: yes|no|user (default)
Where 'user' (please change this!) is the current behavior. In this manner, the default is the current situation where the user has some say, but the developer can express "don't even bother running if everything isn't connected".
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. |
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:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: true|false (default)
stop-when-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. The problem with this approach 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.
Perhaps something like this:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: yes|no|user (default)
stop-when-disconnected: yes|no|user (default)
Where 'user' (please change this!) is the current behavior. In this manner, the default is the current situation where the user has some say, but the developer can express "don't even bother running if everything isn't connected".
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. |
|
| 2016-08-17 15:05:30 |
Jamie Strandboge |
description |
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:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: true|false (default)
stop-when-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. The problem with this approach 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.
Perhaps something like this:
apps:
foo:
daemon: ...
plugs: [ network-control, firewall-control ]
restart-condition: on-failure (default)|never|on-success|on-abnormal|on-abort|always
start-when-connected: yes|no|user (default)
stop-when-disconnected: yes|no|user (default)
Where 'user' (please change this!) is the current behavior. In this manner, the default is the current situation where the user has some say, but the developer can express "don't even bother running if everything isn't connected".
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. |
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|false (default)
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. The problem with this approach 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.
Perhaps something like this:
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: yes|no|user (default)
stop-whenever-disconnected: yes|no|user (default)
Where 'user' (please change this!) is the current behavior. In this manner, the default is the current situation where the user has some say, but the developer can express "don't even bother running if everything isn't connected".
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. |
|
| 2016-08-17 15:08:57 |
Jamie Strandboge |
description |
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|false (default)
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. The problem with this approach 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.
Perhaps something like this:
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: yes|no|user (default)
stop-whenever-disconnected: yes|no|user (default)
Where 'user' (please change this!) is the current behavior. In this manner, the default is the current situation where the user has some say, but the developer can express "don't even bother running if everything isn't connected".
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. |
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. |
|
| 2016-08-17 15:09:24 |
Jamie Strandboge |
summary |
need a way to start daemon only if all interfaces are connected |
optionally start daemon only if all interfaces are connected |
|
| 2016-08-17 15:15:56 |
Adam Stokes |
tags |
|
conjure |
|
| 2018-05-07 13:04:51 |
Zygmunt Krynicki |
snappy: status |
New |
Triaged |
|
| 2023-09-20 13:22:58 |
Michael Vogt |
affects |
snappy |
snapd |
|
