You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All workloads would probably have a Waiting for pebble-ready and all relations should probably have a Blocked: invalid relation data, so might as well offer them by default?
all workloads
all relations
one entry for config (e.g. "Waiting for K8s resource limit patch to apply" which needs to persist across pod churn)
The text was updated successfully, but these errors were encountered:
This feels to me a bit too specific.
What if your charm has no relations? What if your charm is not a k8s charm?
What if you don't care about the status of all relations you have, but only some?
I'm not sure the cost of figuring this out and writing the machinery to implement it offsets the one-time investment the user has to make to set up the StatusPool base class for the charm.
We could write a script to generate for you that code by looking at the metadata.yaml, sure, but that feels like something on top of this lib, not something that this lib should be concerned about.
Yeh, while I think I can see where @sed-i is coming from, this feels like premature optimisation! I think any such functionality would probably be making too many assumptions to be really useful in every case?
All workloads would probably have a
Waiting for pebble-ready
and all relations should probably have aBlocked: invalid relation data
, so might as well offer them by default?The text was updated successfully, but these errors were encountered: