Juju architecture questions

[Thomas Leonard]

On 2012-09-11 17:52, Clint Byrum wrote:
> Excerpts from Thomas Leonard's message of 2012-09-11 09:00:22 -0700:
>> On 2012-09-08 00:55, Clint Byrum wrote:
>>> Excerpts from Thomas Leonard's message of 2012-09-07 08:05:16 -0700:
[...]
>>>> Adding a relation is done (as always) by updating the Zookeeper
>>>> configuration. The units for the services at each end of the relation are
>>>> invoked immediately and simultaneously. Typically, one end will need to run
>>>> first. e.g. when connecting wordpress to mysql, the mysql hook needs to run
>>>> first to create the database. If the wordpress hook runs before mysql has
>>>> updated the configuration it will detect this and exit(0). It will be
>>>> invoked again once mysql updates the settings. This can lead to race
>>>> conditions in charms if the case of running in the wrong order is not
>>>> considered.
>>>
>>> Its really easy to avoid these races though, because you simply exit if
>>> the data you need has not been set yet. The guarantees around the hooks
>>> allow for you to make the assumption that your hook will be invoked again
>>> when the data has changed.
>>
>> I mention this because I got it wrong in my first ever charm. I tested it
>> several times and it worked fine for me, but as soon as I gave it to someone
>> else, it crashed.
>>
>
> I'd be interested in seeing how this failed. It was a common mistake
> early, but we've tried to re-factor some of the documentation and examples
> to make this principle more clear to first-time charm authors.

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.


Thinking about it a bit further, I wonder if it would make sense to split 
add-relation into two steps? That would help with a few problems:

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.

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.

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.

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


What if creating the endpoint were a separate step? e.g.

juju deploy wordpress
juju add-endpoint mysql:wpdb
juju deploy mysql
juju add-relation wordpress mysql:wpdb

Then adding a second service for the same database would be easy, e.g.

juju deploy db-backup
juju add-relation db-backup mysql:wpdb

The above race condition couldn't happen, since add-relation would happen 
after add-endpoint had completed.


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


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


External providers could be supported too:

juju add-endpoint external:db - <<< {JSON}
juju add-relation wordpress external:db


Or are there already ways to do these things?


-- 
Dr Thomas Leonard
IT Innovation Centre
Gamma House, Enterprise Road,
Southampton SO16 7NS, UK


tel: +44 23 8059 8866

mailto:tal at it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk/