search

canonical / charms.reactive

Framework for developing charms and relations using the reactive pattern
Apache License 2.0
22 stars 34 forks source link

Relations with no units still show up in relations list #169

Open johnsca opened 6 years ago

johnsca commented 6 years ago

During the -departed hook relations with no units are removed from the collection, but during subsequent hooks the empty relation is added back into the collection.

Since the relation technically exists, maybe we should not bother removing it from the collection during -departed and just leave it up to the charm author to filter out empty relations if they need to, but I can't really see having access to those empty relations being particularly useful, so maybe it would be nicer to just always filter them out.

hyperbolic2346 commented 6 years ago

I just have a single use-case, but I don't want empty relations in the list. I can't think of a time that knowing a relation exists but has no current units would be useful. Maybe for status reporting?

johnsca commented 6 years ago

Yeah, reporting waiting rather than blocked on a pending relation is about the only time I could see it being helpful, but goal state is a much better solution for that which handles relations that haven't fired the joined hook as well as relations to applications that actually have no units (which should be blocked rather than waiting). So I'm in favor of filtering.

merlijn-sebrechts commented 6 years ago

+1 for filtering.

johnsca commented 6 years ago

For posterity and clarification, since I'm not sure how much the idea of "goal state" has been discussed, it's a proposed feature for Juju which provides the charm with a way to request information about what state the operator has asked Juju to get the model to (at least from the charm's perspective, i.e., what the charm would be able to see once things have settled out) regardless of the actual progress toward that state. It's meant to be purely informative for the charm to report better status messages and possibly optimize its workload somewhat by not performing initialization or doing work that it will soon have to undo anyway (e.g., starting up a local DB to handle no DB relation, when the relation has been requested but not yet established).

Anyway, I don't know that it's any more than just an idea at this point, but it's pretty much on point for the status case I mentioned, which is why I mentioned it.