+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 <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
