Guarantee order of relation-joined & relation-changed?

[Andreas Hasenack]

On Fri, Jul 5, 2013 at 8:43 AM, Stuart Bishop
<stuart.bishop at canonical.com>wrote:

> On Thu, Jul 4, 2013 at 8:28 PM, Gustavo Niemeyer <gustavo at niemeyer.net>
> wrote:
> > On Thu, Jul 4, 2013 at 8:59 AM, Stuart Bishop
> > <stuart.bishop at canonical.com> wrote:
> Yes, I wonder if there should be some way of the charm defining
> priority. Or a way of hooks blocking until particular conditions are
> met. Or a hook being able to fail in such a way that it will be
> automatically retried later. Or a hook being able to trigger an
> arbitrary hook to be run on a particular unit in a particular
> relation.
>
>
I think this will introduce huge complexity to the system. Not only to
actually implement this (think thousands of units firing hooks), but also
to debug issues in the charm.

I think the rules that juju sets should be as simple as possible. That's
the only way it can orchestrate thousands of systems in a way that can be
comprehended and implemented.



> For example, I just noticed another race in the PostgreSQL charm. You
> setup a PostgreSQL service with multiple units, and one is the master
> and the others are hot standbys. Removing the master unit causes a
> failover. All this works fine on my proposed branch. However, if a new
> client relation is added while the failover process is happening,
> there is a reasonable chance that it will never be setup correctly -
> only the master unit can create the new user and database, and during
> the election period there is no master. It is an obscure case, and I
>


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.

One "solution" would be to relate app to db first, wait for it to finish,
and then relate the client to app.

A better one, which I'm experimenting with, might be to allow the client
relate to app, but not give it any data yet, so it can't configure itself
and start working. Once the app is related to db, we revisit this client
and only then call the needed relation-set commands that will allow it to
actually connect.


> suspect most charm developers will not bother to fix it and instead
> just say "don't do that" rather than increase the complexity of the
> charm further.
>
>
It's a possibility. That's why we need good "templates" and patterns to
handle known traps.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130705/ab7325b7/attachment.html>