On 21 January 2016 at 09:51, James Page <james.p...@canonical.com> wrote: > On Wed, 20 Jan 2016 at 20:31 William Reade <william.re...@canonical.com> > wrote: >> >> On Wed, Jan 20, 2016 at 8:01 PM, Dean Henrichsmeyer <d...@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. > > > You didn't - don't worry! > >> >> 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? > > > I Agree with David's +1 on this feature with the condition that it can be > disabled so that charm authors actually understand the behaviour of the > software they are deploying. > > Please lets also ensure the retry limit is sensible - otherwise we might end > up with end-users waiting a loooooong time to understand that something is > not recoverable which could be equally as damaging.
It would perhaps be good if the default status showed that the hook was being retried. On the other hand, if retries become common, then it could be the basis of any number of false-alarm support calls. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
