You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
^ I think it could be better to improve the way restart-commands are run so that they're always given the list of settings that have changed, rather than the setting name having to be in the restart-command itself. That way we can handle dynamic settings, and not have to inspect the system to see what changed.
For example, right now, services.motd could have a restart-command like my-command settings.motd because we know services.motd is only associated with one setting, but services.host-containers is associated with any host container name under settings.host-containers, so we can't pass (hardcode) a single setting. Instead, if the command was given the changed settings, it could alter its behavior based on what changed, like in this case where we need to know which host container changed. (It could also give us the ability to re-use restart command helpers more often, if they can branch on setting.)
What I'd like:
For restart-command helpers likehost-containers to know which settings are being changed so it can determine which host-containers needs to be restarted.
Currently host-containers are not automatically restarted if their settings changed. Users have to explicitly disable and re-enable their host-container via the enabled setting to see their new host-container settings enacted.
It would be great if thar-be-settings can optionally pass the settings being changed to the restart-command being invoked. The restart-command helper would then be able to determine exactly what needs to be done to enact the new setting changes.
Any alternatives you've considered: host-containers can try to infer what settings has changed by checking current settings against previously generated environment files. But this approach is potentially nondeterministic and unelegant.
The text was updated successfully, but these errors were encountered:
I believe this issue has been resolved. Restart command helpers now have access to the list of changed settings via environment variables. The additional work for handling host container restarts when settings change is being tracked in #1531.
Originally posted by @tjkirch in #1230 (comment)
What I'd like:
For restart-command helpers like
host-containers
to know which settings are being changed so it can determine which host-containers needs to be restarted.Currently host-containers are not automatically restarted if their settings changed. Users have to explicitly disable and re-enable their host-container via the
enabled
setting to see their new host-container settings enacted.It would be great if
thar-be-settings
can optionally pass the settings being changed to the restart-command being invoked. The restart-command helper would then be able to determine exactly what needs to be done to enact the new setting changes.Any alternatives you've considered:
host-containers
can try to infer what settings has changed by checking current settings against previously generated environment files. But this approach is potentially nondeterministic and unelegant.The text was updated successfully, but these errors were encountered: