I’ve discussed some aspects of this with @kyrofa on IRC, this is indeed a problem as the service that’s being restarted from configure hook doesn’t see the new values from snapctl get ..., due to transactional nature of configure hook.
Here is what has been discussed as possible solutions:
- A way for
configurehook to queue commands that restart the service after configure hook succeeds, e.g.snapctl queue -- snapctl restart apache. - A new
post-configurehook executed afterconfigurehook succeeds. It could implement logic for restarting services. This is problematic though as it would need to know what config values have changes and what needs restarting based on these values - cumbersome. - Discussed briefly, clearly hypotetical and probably problematic if possible at all (mentioning just for the record): see if it’s possible for the restarted service to “see” the cookie/context env var of the
configurehook transaction, so calls tosnapctl get ...done by the service see new uncomited values. As indicated this has issues, e.g. it breaks transactional nature of setting a configuration (service may be running with a configuration that failed to apply), it eventually leaves the service with context/cookie which is supposed to be ephemeral (transaction gets commited eventually, context is gone). - A way for snapctl to explicitely commit config changes when asked to, e.g.
snapctl commitso thatconfigurehook can control this aspect and restart services next with new changes in place. This feels a bit hacky though, configure is no longer fully transactional, complexity grows.
I hope that captures the points we discussed. Thoughts?