Guarantee order of relation-joined & relation-changed?

[Matthew Wedgwood]

I don't think the success of configuration equates with the proper operation of the unit. The application should be *configured* properly at the end of a hook, but that doesn't necessarily mean it can do its job.

On 07/04/2013 06:59 AM, Stuart Bishop wrote:
> If the new client unit's hooks happen to be run before the database 
> unit's hooks, then the client will find and attempt to use these 
> authentication credentials. This will fail because the server has yet
> to grant access to the new client unit's IP address.

In this case the hook hasn't failed, only the client connection. Shouldn't the client retry the connection? There are other reasons besides hook ordering that the connection might fail. Network unreliability, for one example.

Even if the hooks fired in the most favorable order, won't the new client unit fail (or be offline) until those relation hooks fire?

On 07/05/2013 07:38 AM, Andreas Hasenack wrote:
> I was pondering about a similar problem yesterday. I have a case 
> where an application needs several services to be up and running and 
> related before it can start working. Simplifying the case, it's app 
> and db, and the third actor (the client) can only be added and 
> related to app once app and db are related.
> 
> So if you deploy the three services and relate them to each other 
> immediately, there is a big chance that the client relation will 
> fail, because the app wasn't related to the DB yet.

Again, why should the relation fail? If the app isn't related to the DB, the client will simply receive error responses/timeouts from the app, right? There's no guarantee that the app can always talk to the database, even when the relation is fully established.

If you're implying that the appserver passes along some information to the client from the database, then I would expect the app to run relation-changed (on the client's relation) when the database relation was established.