Automatic retries of hooks

[Charles Butler]

I'm pretty sure that we have amenities to reboot the host without
completely skewing the hook execution

https://jujucharms.com/docs/1.25/reference-hook-tools#juju-reboot-[--now]

This should have rebooted the machine after safely closing out of any hook
context the charm was in, and upon reboot it should have resumed from the
next context in queue.  I'm not a huge fan of a charm doing auto hook
retries, for the reasons outlined by Rick, unless it is well understood and
documented behavior.  Just chiming in with my 2 cents


Charles Butler <charles.butler at canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Wed, Jan 20, 2016 at 9:22 AM, Rick Harding <rick.harding at canonical.com>
wrote:

> +1 retries are great, with backoff, when you know you're doing it because
> you have experience that certain api requests to clouds, or to other known
> failure points.
>
> Blindly just saying "if at first you don't succeed, go go go" isn't a
> better UX. It adds another layer of complexity in debugging, and doesn't
> really improve the product. Only the charm author knows enough about what
> it's trying to achieve to do intelligent retry.
>
> In this case, if there's something about unexpected reboots of machines,
> perhaps there's some specific case that Juju can grow some intelligence and
> hint at the charm author what happened. The charm can then react to that
> information as it deems necessary.
>
> On Wed, Jan 20, 2016 at 8:42 AM Dean Henrichsmeyer <dean at canonical.com>
> wrote:
>
>> Hi,
>>
>> It seems the original point James was making is getting missed. No one is
>> arguing over the value of being able to retry and/or idempotent hooks.
>> Yes, you should be able to retry them and yes nothing should break if you
>> run them over and over.
>>
>> The point made is that Juju shouldn't be automatically retrying them. The
>> argument of "no one knows what went wrong so Juju automatically retrying
>> them is a better experience" doesn't work. The intelligence of the stack in
>> question, regardless of what it is, goes in the charms. If you start
>> conflating and mixing up where the intelligence goes then creating,
>> running, and debugging those distributed systems will be a nightmare.
>>
>> The magic should only be in Juju's ability to effectively drive the
>> models and intelligence encoded in the charms. It shouldn't make
>> assumptions about what that intelligence is or what those models require.
>>
>> Thanks.
>>
>>
>> -Dean
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
> --
> 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/20160120/f65984ee/attachment.html>