Should collect-status events only be triggered after observed events? #1265
Assignees
Labels
needs design
needs more thought or spec
Comments
|
We discussed briefly and consider this too problematic to change now for backwards-compatibility reasons. For example, when James was building his demo charm he used this "feature". |
|
@james-garner-canonical is going to add a little note in the docs to clarify. |
tonyandrewmeyer
pushed a commit
to tonyandrewmeyer/operator
that referenced
this issue
Oct 4, 2024
…ok (canonical#1399) For backwards compatibility, collect-status will continue to run at the end of every hook, even if the charm does not provide any observers for that hook. Make this explicit in the documentation. Closes canonical#1265.
tonyandrewmeyer
pushed a commit
to tonyandrewmeyer/operator
that referenced
this issue
Oct 9, 2024
…ok (canonical#1399) For backwards compatibility, collect-status will continue to run at the end of every hook, even if the charm does not provide any observers for that hook. Make this explicit in the documentation. Closes canonical#1265.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In our discussion of @tonyandrewmeyer's change-updated spec OP045, we noted that collect-status events are currently run at the end of every hook. This is as designed and documented as "Event triggered at the end of every hook to collect statuses for evaluation."
However, @hpidcock noted that this is probably not ideal, and they should only be triggered after every hook that the charm is observing (with
Framework.observe). For one thing, it's easier to cause an infinite loop of events if the charm is doing something odd in collect-status which triggers another event.We should think through the pros/cons of this and decide whether to change it or not (changing it would strictly-speaking be backwards incompatible, but that may be acceptable here).
The text was updated successfully, but these errors were encountered: