First customer pain point pull request - default-hook

[Michael Nelson]

On Wed, Aug 20, 2014 at 3:07 AM, Aaron Bentley
<aaron.bentley at canonical.com> 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
>> <aaron.bentley at canonical.com> 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
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev