Automatic retries of hooks

[Nate Finch]

To anyone who is not the author/maintainer/deeply knowledgeable about a
charm, a hook error is doom.  There is only one hammer an average user of
Juju can use in that case, and it's juju resolved --retry.  If we can do
that automatically for our users, then it can be a big help to cover up for
an imperfect charm (and no charm is perfect).  The range of transient
things that can go wrong is infinite, and it's unrealistic to assume every
single charm will handle every single problem.  Not to mention that some
problems are simply not possible to handle (OOM, reboot, etc). This can
only make Juju more reliable and more user-friendly.

The knowledge level of people like Dean and James is *far *beyond that of
an average user of Juju.  When they see a hook error, they can go analyze
the logs and status output and figure out whether an error is likely to get
resolved by a retry, and know if the charm should be updated to account for
this case.  But we shouldn't expect average users to have that depth of
knowledge.

Yes, we should absolutely be able to turn off hook retries in the
environment config, specifically for dev, testing, and expert users like
those in our organization.  But by default, they should retry.  To do
otherwise would be a disservice to our users.

On Wed, Jan 20, 2016 at 3:31 PM William Reade <william.reade at canonical.com>
wrote:

> On Wed, Jan 20, 2016 at 8:01 PM, Dean Henrichsmeyer <dean at canonical.com>
> wrote:
>>
>> You realize James was complaining and not celebrating the "success" ? The
>> fact that we can have a discussion trying to determine whether something is
>> a bug or a feature indicates a problem.
>>
>
> Sorry, I didn't intend to disparage his experience; I took it as
> legitimate and reasonable surprise at a change we evidently didn't
> communicate adequately. But I don't think it's a misfeature; I think it's a
> necessary approach, in service of global reliability in challenging
> environments.
>
> But: if there are times it's inconvenient and not just surprising, we
> should surely be able to disable it. Gabriel/Bogdan, would you be able to
> address this?
>
> Cheers
> William
> --
> 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/7b5b408b/attachment.html>