Juju architecture questions

[Gustavo Niemeyer]

On Wed, Sep 12, 2012 at 6:25 AM, Thomas Leonard
<tal at it-innovation.soton.ac.uk> wrote:
> The documentation was fine, but I didn't look at that aspect in detail until
> it failed. My (wrong) intuition was that Juju would either (most likely) run
> the provider hooks first and my charm would always work, or (less likely)
> run them second, and it would fail reliably when tested. I hadn't considered
> that there might be a race.

Calling it a race seems to imply that there's a chance that setting
changes can be lost or that a correct charm can misbehave. That's not
the case. What we have is lack of definition of the initial order of
execution, which means both charms can start executing immediately,
and both can easily bail out and wait for the other side to do
something they care about. All setting changes are observed after
performed.

That said, I agree that defining an order of execution would simplify
the mental model. This has a cost, though, and it's not clear if the
benefit outweights that cost given it's trivial to handle the current
mechanism and there are also benefits about doing it that way. We can
wait a bit and see how people relate to it in general.

> 1. You can't, I think, create a database with multiple clients (e.g. a
> wordpress web-server service and a backup service), because each relation
> will create a new database.

You can do whatever you want in a relation, so this isn't really true.
I agree that there are more things we can do to simplify that kind of
hand-tunning, and we have a few ideas in the pipeline for the near
future that will help. One idea that is floating and requires some
careful consideration after we're done with the current stack of
development is introducing relation-bounded settings. This will help
with some of the cases you're bringing up.

> 2. I'm not sure how to create the amqp-ssl interface mentioned in
> https://code.launchpad.net/~tal-it-innovation/charms/precise/rabbitmq-server/ssl-support/+merge/122698
> only when SSL is configured.

The interface exists at all times. The way it behaves when established
is a choice for the charm author. If I had to make such an SSL
relation available, I'd automatically build an SSL certificate on
first use when required, for example, rather than loading the admin
with further instruction on how to setup the charm.

> 3. Having external (i.e. not deployed by Juju) clients or providers is
> tricky. e.g. you can't create a MySQL database for use by a desktop client,
> or configure a Juju wordpress service to connect to an existing database.

It is possible to create proxy charms today to reflect external
services. There's some polishing we have to do on that area to improve
support for it, but it's already possible.

> 4. There doesn't seem to be a way to remove a relation cleanly (e.g. giving
> the DB client a chance to write buffered data first).

Indeed, that's a use case we can improve over time.

> What if creating the endpoint were a separate step? e.g.
(...)
> The above race condition couldn't happen, since add-relation would happen
> after add-endpoint had completed.

As explained, there's no real race condition, and if we wanted to
modify the behavior we wouldn't really have to change the API for
that.

Explicitly defining endpoints as you suggest adds yet another piece
onto the mental model that has to be held for comprehending the
system. The fact we're doing well without that piece so far is an
indication that we can probably address the needs without making the
simple cases complex.

> Adding SSL endpoint(s) to rabbit would be easy:
>
> juju deploy rabbitmq-server rabbit
> juju add-endpoint rabbit:ssl ssl=True key=...
> juju add-relation client rabbit:ssl

It's easier today:

    juju add-relation client rabbit:ssl

> External clients could get the connection information even though not
> deployed using Juju. For example, if I want to create a database for use by
> a desktop client:
>
> juju add-endpoint mysql:mydb
> juju get mysql:mydb
> {JSON}
>
> Also, this would be handy:
>
> juju get nagios:admin password

For now, you can either check the logs (which isn't nice) or set it explicitly:

    juju set nagios admin-password=<your password>

But there's indeed a story about pushing user-oriented details from a
charm to the admin that we must cover in the future. That's unrelated
to the other points raised in this thread, though.

> Or are there already ways to do these things?

There is for most of them.

By the way, I'd just like to take this chance to say that I was pretty
impressed with your initial analysis of the system.

Can I ask what are you planning for juju, and whether there's any way
we can help you moving forward?


gustavo @ http://niemeyer.net