First customer pain point pull request - default-hook
Matthew Williams
matthew.williams at canonical.com
Tue Aug 19 21:58:26 UTC 2014
Something to be mindful of is that we will shortly be implementing a new
hook for metering (likely called collect-metrics). This hook differs
slightly to the others in that it will be called periodically (e.g. once
every hour) with the intention of sending metrics for that unit to the
state server.
I'm not sure it changes any of the details in this feature or the pr - but
I thought you should be aware of it
Matty
On Tue, Aug 19, 2014 at 6:07 PM, 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.
>
> So I think it's a bigger win to focus on the application domain and
> ignore the hook names.
>
> > 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.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140819/6f660088/attachment-0001.html>
More information about the Juju-dev
mailing list