relation departure timing changes

[Stuart Bishop]

On Thu, Aug 22, 2013 at 11:42 PM, William Reade
<william.reade at canonical.com> wrote:

> 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).

I need to see this in more concrete terms.

So lets say we have a provider (server_service), a requirer
(client_service), and they are related (relname).

Currently, if we remove-unit server_service/0 there is a chance that
the the unit is removed while the client_service is still using it,
causing errors. In addition, if we remove-unit client_service/0 there
is a chance that server_service revokes access before the client unit
is shutdown, causing errors.

With my interpretation of the proposed changes:

If we 'remove-unit server_service/0':
  1) server_service/0 is flagged as dying and relation-list stops listing it.
  2) If there are any relname-relation-joined client_service hooks for
server_service/0 pending, they are thrown away.
  3) Wait until any relname-relation-joined hooks for server_service/0
currently in progress are completed.
  4) relname-relation-departed is run on all the client_service units.
The dying server_service/0 doesn't yet know it is dying, so
client_service can continue to to use it while the departed hooks are
being run.
  5) Wait until all the relname-relation-departed hooks have completed
  6) Fire relname-relation-broken on server_service/0
  7) Once all *-relation-broken hooks have completed, stop and kill
server_service/0

However, if instead we 'remove-unit client_service/0':
  1) If there are any relname-relation-joined server_service hooks for
client_service/0 pending, they are thrown away.
  2) Wait until any relname-relation-joined hooks for client_service/0
currently in progress are completed.
  3) Fire relname-relation-broken on client_service/0.
  4) Wait until all *-relation-broken hooks have completed on
client_service. At this point, it is no longer in use.
  5) Fire all the relname-relation-departed hooks for server_service/0
and stop and kill client_service/0

Is this correct? As far as I can see, existing charms are no worse off
with this model but there is good chance client/server relations will
benefit; clients are shutdown before the servers cut off their access,
and servers are shutdown after clients stop making use of them.

-- 
Stuart Bishop <stuart.bishop at canonical.com>