Juju architecture questions

[Clint Byrum]

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:
> >> 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
> >
> > Its pretty close. You missed the provisioning agent though.
> >
> > https://docs.google.com/drawings/d/1Az4cx4w6J3dvJfQmg8ZbrOIx8vSuBFhYcaP0nHYUHEQ/edit
> >
> > Its existence helps understand a lot of the things you're confused about.
> 
> Ah, thanks - that explains a lot! I can't view your document though ("You 
> need permission to access this item").
> 

Oops! Fixed

> >> 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? ]
> >>
> >
> > Only environments.yaml must be shared if you are using the official charm store.
> > If you are using local: charms, then you need to share the charm repository too.
> 
> If this just so they can be upgraded? I assume even local charms are copied 
> to the S3 bucket the first time they're deployed?
> 

Once deployed once, yes, you can re-deploy that charm over and over
without a local copy. For upgrades or for new deploys, you need a copy.

> [...]
> >> 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.