On Wed, Aug 20, 2014 at 3:07 AM, Aaron Bentley <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 14-08-19 12:46 PM, Gustavo Niemeyer wrote: >> On Tue, Aug 19, 2014 at 1:10 PM, Aaron Bentley >> <[email protected]> wrote: >>> True. At that point, the pattern is not a win, but it's not much >>> of a loss. Changing the web site relation is extremely uncommon, >>> but operations which do require server restarts are quite common. >>> So making an exception for the web site relation can be seen as >>> a micro-optimization. >> >> Restarting a process and killing all on-going activity is a big >> deal more often than not, for realistic services. > > Sure, if we *were* to optimize this, we'd want to restart only on > certain kinds of changes. But I'd argue that it's better to optimize > that in the application domain than based on hook names. > > For example, changing the cron interval does not require restarting > the web server, but changing the http port does. Both use the same > hook, config-changed. > > Instead of restarting the web server unconditionally, we could restart > it when the contents of its config file change. That would avoid a > restart when cron interval changes, and also when > webserver-relation-changed fires.
+1, we do the same thing (well, ansible does it for us). For example, this simple task: https://pastebin.canonical.com/115614/ tells ansible to re-render the config file on config-changed and *-relation-changed, but it will only notify the 'Restart wsgi' handler if the config changes (in fact, the config file will only be touched if the template rendering results in a diff from the existing one). > > So I think it's a bigger win to focus on the application domain and > ignore the hook names. Hrm - so with the above task, I could instead ignore the hook names and have it run for any hook (or the new default-hook) - it would still only update the config file and restart when the file changes. But I've only got it running for those 3 hooks because I know that's when it needs to be checked (ie. I know that I don't need to run it on *-relation-joined, only -changed etc.). Perhaps it's only a small efficiency gain for a potential mistake on my part. > >> The point I was trying to convey is not that you can merge or >> ignore certain events. The system was designed so that this was >> possible in the first place. The point is rather that the existing >> event system is convenient and people rely on it, so I don't buy >> that a "something-changed" hook is what most people want at this >> point. > > Fair enough. More evidence would be needed to determine whether I'm > an outlier. I'm keen to try updating one of my charms to do this, but am not doing so currently. -Michael > > Aaron > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJT84RTAAoJEK84cMOcf+9hmXEIAIc74ywBWOMybk6tVZh0sT/r > 0GBt/AhDVRfzAt75rZGzuwlQLvu3tyAwY6yu0ROAdnW+dmJf5yGwJUAIDR3V0kcu > kO866sXDmTysPs8vmiku1xFhFnwbxaJEJWG67zcUOacsl8fHaxMDH0ufm8YoOGgR > fs6VtLp283wm1rYmeXwZ8FkZ7QRQZYwFZ9gNpXCjKHdSbW/yaT4o1HC7+MgeG3Cc > mwPLWl2qQGHXxB6Jc2Bb+ebBw8WTSRNvpS4UmrMSzbbdqvlaytuJuRP6ansYTVYi > X5I+CBWDbbImZBfEADCkQPYk1jX1GlinoQuInbnGrftViyQ/KTEXzzAEIJcRIGE= > =bqp0 > -----END PGP SIGNATURE----- > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
