I do think that you won't typically have application data until the first
unit of an app sets it. Which is why you wouldn't see an early app data
changed. Whether you would see app changed before or after a unit joined
would be ordering, I think. If an app is already deployed and you launch a
new app and relate it. Then relation-created is going to fire on the
running units, while the new machine is still starting.

That doesn't exist today. Which means the unit doesn't know the relation
exists until a unit joins it.

An example probably helps:

Today:

mysql/0 up and running
juju deploy wordpress
juju relate wordpress mysql

* wait for wordpress/0 to start
* relation-joined fires on both wordpress and mysql "simultaneously"
* relation-changed is hard coded to fire immediately after -joined
* each one sees the relation and can potentially set app data or unit data

Future
* after 'juju relate' I would expect relation-created to fire on mysql
while waiting for wordpress/0
* wordpress/0 will also see relation-created before it gets to start
* once start, relation-joined will fire simultaneously for both

at some point you would see relation-changed app due anything set during
the relation-changed event

similarly 'juju add-unit wordpress'

* at some point wordpress/1 will be made aware of the application data from
mysql. should it be before/after relation-joined?

If we go back to the discussion we had today, one interesting feature of
deferring app relation changed is that it could conceivably happen after
you've been told about all the currently running units of app. So code that
doesn't want to spin for each unit could wait until it sees the first app
changed before handling any of those events (just like deferring until
start to know that you've seen most of the things you're related to)

We can never guarantee that you've seen *everything* (concurrency means
that some of them haven't finished starting yet).  But you could fast path
a lot of the one by ones until you get there.

John
=:->

On Mon, Mar 16, 2020, 17:15 Dmitrii Shcherbakov <email address hidden>
wrote:

> > However, is it correct for Apache/1 to have the config from vhost_rdata
> if
> its associated dummy-vhost/1 hasn't actually started up yet?
>
> I don't think it is. It definitely feels like a use-case for unit data
> bags with a container-scoped relation. I think this example is useful
> for demonstration purposes only.
>
> We could just say that this is a valid sequence of events:
>
> 1) relation-created;
> 2) relation-changed (app data);
> 3) relation-joined;
> 4) relation-changed (remote unit data).
>
> And then charms and the framework itself would have to handle that
> situation gracefully for subordinates.
>
> It is quite specific to container-scoped relations because it seems like
> for global-scoped ones this sequence should always be the case:
>
> 1) relation-created;
> 2) relation-joined;
> 3) relation-changed (app or unit data).
>
> I may be wrong in my assumption because the relation-created feature
> isn't there yet.
>
> What do you think?
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1866828
>
> Title:
>   [2.7.4] relation-changed events for container-scoped app relation data
>   may fire for primary units before they see their own subordinate
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1866828/+subscriptions
>