Re: Automatic retries of hooks

2016-01-21 Thread roger peppe
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

Re: Automatic retries of hooks

2016-01-21 Thread James Page
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

Re: Automatic retries of hooks

2016-01-20 Thread Gabriel Samfira
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

Re: Automatic retries of hooks

2016-01-20 Thread William Reade
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

Re: Automatic retries of hooks

2016-01-20 Thread Aaron Bentley
-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

Re: Automatic retries of hooks

2016-01-20 Thread Gabriel Samfira
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,

Re: Automatic retries of hooks

2016-01-20 Thread Stuart Bishop
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

Re: Automatic retries of hooks

2016-01-20 Thread Dean Henrichsmeyer
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

Re: Automatic retries of hooks

2016-01-20 Thread William Reade
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

Re: Automatic retries of hooks

2016-01-20 Thread Gabriel Samfira
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

Re: Automatic retries of hooks

2016-01-20 Thread Martin Packman
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: >

Re: Automatic retries of hooks

2016-01-20 Thread roger peppe
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

Re: Automatic retries of hooks

2016-01-20 Thread Rick Harding
+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,

Re: Automatic retries of hooks

2016-01-20 Thread Dean Henrichsmeyer
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

Re: Automatic retries of hooks

2016-01-19 Thread Stuart Bishop
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