When to send an application into an error state

[zicklag]

@jameinel

I’m actually rather surprised that an error in one charm would cause an error in another. If one application goes into an error state, then it doesn’t set any relation data for the other application to read.

Actually I don’t mean erroneous data passed over charm relations, I mean

@zicklag

I ran into a situation where I had an HTTP proxy charm that had a bug that caused a hook failure under certain conditions. I related this HTTP proxy charm ( not knowing about the bug ) to a Grafana charm. When the proxy charm went into an errored state the only way to fix it was to force remove the charm. I force removed the proxy charm, but then Grafana’s hook errored out, not because of a bug in Grafana, but because the charm’s Juju agent was eternally trying to respond to a relation hook event on a relation that no longer existed, since the force removal of the proxy.

The problem is when a charm ran into an internal charm error and I had to force remove it. The force removal of one charm is what broke the other charm.

I did get a good point from @thumper on that, though.

@thumper

As I’m sure you have noticed, Juju will automatically retry hook errors. However there is a command that you can use to tell the Juju controller (and model) that you have handled the situation.

juju resolved --no-retry <unit-name>

This will effectly remove the error state from the unit for the current hook execution. Juju then moves on to the next thing it would run for that unit. Frequently this is another hook.