Hi all This is inspired by the "relation-list reporting dying units" bug [0], which can be reasonably simply fixed by reporting peer units' departure from a relation as soon as we know that they're being destroyed (rather than *after* the unit has handled the departure as we currently do [1]).
I'm not aware of any reason this measure might be controversial (please let me know if you are); but it raises an interesting question whose answer hinges on common practice across the charm community. So far, there has been no practical distinction between relation providers and requirers; we're considering introducing an asymetry in the relationship, such that providers signal departure early as above (but requirers continue to signal departure only once they have actually departed). This makes intuitive sense given the names of the roles; but it only makes practical sense if requirers and providers are written such that, essentially, requirers connect to providers and not vice versa. Many charms certainly do work this way, and would thus benefit from such a change; but it's hard to audit this behaviour across the charm ecosystem. However, I'd like to know if anyone is aware which charms (or, most likely, entire interfaces) would *not* work correctly if we were to introduce this behaviour; this will help us figure out if, when, and how to do so. Cheers William [0] https://bugs.launchpad.net/juju-core/+bug/1192433 [1] https://juju.ubuntu.com/docs/authors-charms-in-action.html -- "Departing relations"
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
