On 21 January 2016 at 09:51, James Page wrote:
> On Wed, 20 Jan 2016 at 20:31 William Reade
> wrote:
>>
>> On Wed, Jan 20, 2016 at 8:01 PM, Dean Henrichsmeyer
>> wrote:
>>>
>>> You realize James was complaining and not
On Wed, 20 Jan 2016 at 20:31 William Reade
wrote:
> On Wed, Jan 20, 2016 at 8:01 PM, Dean Henrichsmeyer
> wrote:
>>
>> You realize James was complaining and not celebrating the "success" ? The
>> fact that we can have a discussion trying to
On Mi, 2016-01-20 at 10:39 -0500, Aaron Bentley wrote:
> On 2016-01-20 10:30 AM, Gabriel Samfira wrote:
> > The auto-retry thing was created to overcome situations in which
> > the machine is rebooted, or chashes during a hook run
> > (independently of juju). In this case, the charm would not be
On Wed, Jan 20, 2016 at 2:42 PM, Dean Henrichsmeyer
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2016-01-20 10:30 AM, Gabriel Samfira wrote:
> The auto-retry thing was created to overcome situations in which
> the machine is rebooted, or chashes during a hook run
> (independently of juju). In this case, the charm would not be able
> to
The auto-retry thing was created to overcome situations in which the machine is
rebooted, or chashes during a hook run (independently of juju). In this case,
the charm would not be able to recover automatically from a transient situation.
This scenario is more evident in Windows workloads,
On 20 January 2016 at 17:46, William Reade wrote:
> On Wed, Jan 20, 2016 at 8:46 AM, Stuart Bishop
> wrote:
>> It happens naturally if you structure your charm to have a single hook
>> that does everything that needs to be done, rather
On Wed, Jan 20, 2016 at 11:41 AM, William Reade wrote:
> On Wed, Jan 20, 2016 at 3:22 PM, Rick Harding
> wrote:
>
>> +1 retries are great, with backoff, when you know you're doing it because
>> you have experience that certain api
On Wed, Jan 20, 2016 at 8:01 PM, Dean Henrichsmeyer
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
On Mi, 2016-01-20 at 21:31 +0100, William Reade 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
Another common error we see in CI is apt mirrors being unhappy leading
to hook failures. Just retry later does tend to be the right option
there, though it will often be an our or two until the archive is in a
usable state again.
On 20/01/2016, William Reade wrote:
>
On 20 January 2016 at 12:20, Martin Packman
wrote:
> Another common error we see in CI is apt mirrors being unhappy leading
> to hook failures. Just retry later does tend to be the right option
> there, though it will often be an our or two until the archive is in a
+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,
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
On 20 January 2016 at 13:17, John Meinel wrote:
> There are classes of failures that a charm hook itself cannot handle. The
> specific one Bogdan was working with is the fact that the machine itself is
> getting restarted while the charm is in the middle of processing a
15 matches
Mail list logo