Juju architecture questions

Fri Sep 7 15:05:16 UTC 2012

Is there a diagram somewhere showing how all the different bits of Juju fit 
together?

I found it quite confusing when I read the tutorial for the first time, and 
there are still bits that I'm not sure about. I tried making a diagram to 
show the example (wordpress + mysql). It's probably wrong, but maybe someone 
could correct it?

https://docs.google.com/drawings/d/1LVrBjoMivIQZf6TNaquA5dFrZcd2x2Cj_XNB2GBPaA0/edit

Here's my understanding so far (please correct):

The Juju admin has the environment.yaml and the data directory. Together, 
these give access to the system and could be shared with other admins, 
allowing them to manage the system together.

[ which bits of the data directory need to be shared, and which are just log 
files and temporary files? do the admins need to sync anything manually 
between their systems? ]

For EC2, bootstrap deploys a new machine and runs Zookeeper on it to store 
all the configuration settings. Charms and other files are uploaded to an S3 
bucket.

For a local deployment, Zookeeper and a Python web-server are run on 
localhost. No new machines or containers are created at this point.

When a new service unit is deployed to EC2, a new machine is created.
For local deployments, a new LXC container is created on localhost. Juju 
considers local deployments to consist of a single machine, but with 
multiple containers (container != machine). EC2 machines do not use 
containers, although there are plans to change this ("LXC everywhere").

For every "machine", a "machine agent" process runs on that machine. It 
monitors the Zookeeper service looking for changes to the set of units it is 
supposed to be running.

Deploying a service writes the configuration for the new service and for a 
single initial unit of it to Zookeeper. The machine agent notices the change 
and deploys the actual charm (downloading it from S3 and running its install 
hook).

For each running unit, there is a "unit agent". The unit agent watches the 
Zookeeper configuration for configuration changes and runs the charm's hooks 
as needed. The unit agent runs within the LXC container (if any) along with 
the actual running service.

Destroying a service or unit removes it from the Zookeeper configuration. 
The machine agent then destroys the LXC container. [ what happens for EC2? ]

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.

What needs access to what?

- The admin needs complete access to everything. Deploying new machines is 
done directly by the admin's machine, but everything else is done indirectly 
by updating Zookeeper.

- Machine agents need access to all units, so they can search for the ones 
they want. They also need read-only access to S3 to download charms.

- Units need read-only access to their service configuration, and read-write 
access to their relations, whether providing or requiring.

- The EC2 credentials are stored in Zookeeper too. [ why? ]