On Wed, Aug 20, 2014 at 12:29 AM, Kapil Thangavelu < kapil.thangav...@canonical.com> wrote:
> hmm.. there's three distinct threads here. > > default-hook -> charms that do so symlink 0-100% -> to one hook.. in > practice everything, sometimes minus install (as the hook infrastructure > needs pkgs).. and most typically implemented via dispatch table. > And AFAICS everybody agrees it's nice, and we seem to be approaching consensus re JUJU_HOOK_NAME. something-changed -> completely orthogonal to either the default-hook merge > request, and in practice full of exceptions, but useful as an optimization > of event collapsing around charms capable of event coalescence > Not *entirely* orthogonal -- they do similar *enough* jobs that you wouldn't want to implement both in the same charm -- but, yeah. I'm happy to discuss that further (new thread maybe?) but I don't think it's under immediate consideration anyway. periodic async framework invoked -> metrics and health checks. afaics best > practices around these would be not invoking default-hook which is > lifecycle event handler, while these are periodic poll, yes its possible > but it conflates different roles. > Not so sure about this. By "lifecycle events", do you mean "all the events we have hitherto communicated"? I'm not sure the distinction between old and new will be intuitively clear, and I don't think the consequences of triggering default-hook are serious -- on that front I reserve my concern for the introduction of hook contexts with surprising features, but again I think there's a happy path we can walk by requiring opt-in to such features. Cheers William
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
