Open rgildein opened 1 month ago
Essentially this is a communication challenge between the lib and the charm, because we don't have a decentralized status setting mechanism (yet). We have a convention in the team that charm libs do not touch charm status, because they don't have the full context.
We could emit a custom event or add a get_status
method (to be used in a charm's collect-unit-status
), but in either case the charm author would need to read the docs to become aware of the details.
(We don't want an exception to avoid breaking the charm on upgrade).
So it seems like charm code should check for juju version itself. Leaving the issue open to add a code example in the module docstring for this.
Related:
Bug Description
If the charm is deployed on <Juju 3.4, LogForwarder only provides a warning log message that Juju 3.4 is required, however this behavior is misleading, and I believed a better solution would be to put the charm into a block state until the relation is removed. The charm works fine with this relation, but the user can easily assume that all logs are going to Loki until something goes wrong and the service needs to be debugged.
To Reproduce
Environment
Relevant log output
Additional context
No response