^^ s/immutability/idempotency On Thu, Jan 5, 2017 at 12:39 PM, Casey Marshall < [email protected]> wrote:
> On Thu, Jan 5, 2017 at 3:33 AM, Adam Collard <[email protected]> > wrote: > >> Hi, >> >> The automatic hook retries[0] that landed as part of 2.0 (are documented >> as) run indefinitely[1] - this causes problems as an API user: >> >> Imagine you are driving Juju using the API, and when you perform an >> operation (e.g. set the configuration of a service, or reboot the unit, or >> add a relation..) - you want to show the status of that operation. >> >> Prior to the automatic retries, you simply perform your operation, and >> watch the delta streams for the corresponding change to the unit - the >> success or otherwise of the operation is reflected in the unit >> agent-status/workload-status pair. >> >> Now, with retries, if you see a unit in the error state, you can't >> accurately reflect the status of the operation, since the unit will >> undoubtedly retry the hook again. Maybe it succeeds, maybe it fails again. >> How can one say after receiving the first delta of a unit error if the >> operation succeeded or failed? >> >> With no visibility up front on the retry strategy that Juju will perform >> (e.g. something representing the exponential backoff and a fixed number of >> retries before Juju admits defeat) it is impossible to say at any point in >> the delta stream what the result of a failed-at-least-once operation is. >> > > I think the retry strategy is great -- it leverages the immutability we > expect hooks to provide, to deliver a robust result over unreliable > substrates -- and all substrates are unreliable where there's > internetworking involved! > > However I see your point about the retry strategy muddling status. I've > noticed this sometimes when watching openstack or k8s bundles "shake out" > the errors as they come up. I don't think this is always a charm quality > issue, it's maybe because we're trying to show two different things with > status? > > >> What if Juju made a clearer distinction between result-state ("what I'm > doing most recently or last attempted to do") vs. goal-state ("what I'm > trying to get done") in the status? Would that help? > > >> Can retries be limited to a small number, with a backoff algorithm >> explicitly documented and stuck to by Juju, with the retry attempt number >> included in the delta stream? >> >> Thanks, >> >> Adam >> >> [0] https://jujucharms.com/docs/2.0/reference-release-notes >> [1] https://jujucharms.com/docs/2.0/models-config#retrying-failed-hooks >> >> -- >> Juju-dev mailing list >> [email protected] >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju-dev >> >> >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
