Juju Development Notes

Notes for getting started with Juju

Read the Juju Getting Started Guide
- The two lines in your existing $HOME/.ec2/aws_id are the access-key and secret-key for the environments.yaml file.
- If you want to use the PPA for juju (recommended at this time), make sure you set juju-origin: to ppa.
Create a directory for your charms. Mine is $HOME/juju -- lets call it $JUJUDIR
Get the buildbot-master charm from lp:~yellow/launchpad/buildbot-master and put it in $JUJUDIR.
Charms are specific to a series. Since we're deploying oneiric, all charms are expected to be found in an oneiric subdirectory. So create $JUJUDIR/oneiric and from inside it ln -s ../buildbot-master.
- The following commands should get you up and running:

cd $JUJUDIR
juju bootstrap -e local  # Assuming you called your LXC configuration in environments.yaml 'local'
juju deploy --repository=. local:buildbot-master
watch juju status  # wait for the state to be 'started'
juju expose

You should then be able to go to http:<local_ip_address>:8010 and see the buildbot page for pyflakes.

Notes for hacking on Juju

Juju uses trial, the Twisted test runner. Its semantics are different from Zope's testrunner. To run a single test you must provide the full (pythonic) path to that test:

 $ ./test the.path.to.the.TestCase.and_test

There are some tests which will always fail if you don't have your EC2 credentials in your ENV. There's debate about whether these tests should be made to not depend on the ENV variables.
The same tests look like they try to connect to EC2 but apparently don't. There's debate about whether they should or not.
Because juju is all Twisted, the tests run inside a reactor. This means that if you're debugging the reactor will swallow a CTRL-C and just report an error for every subsequent test. Upshot test narrowly when debugging.

Notes for working with Juju

Juju is broken with precise and vmware when trying to use a local environment. 920454. Oneiric/vmware/local works as does Precise/metal/local.

Notes for working with Juju Charms

You can only pass in config options as strings to juju set. If you want to upload an entire config file, you need to do something like:

 $ juju set my-service option=$(uuencode /path/to/config/file)

juju debug-log is broken (well, juju-log on the units is broken, but the upshot is that it won't get reflected if you run juju debug-log on your local machine). Brad has a workaround:

(On the client)
root@ip-10-116-73-15:/# grep unit.hook.api /var/lib/juju/units/$UNITNAME/charm.log
2012-01-17 20:51:17,315: unit.hook.api@INFO: --> install
2012-01-17 20:51:20,588: unit.hook.api@INFO: Creating master in /tmp/buildbot
2012-01-17 20:51:23,539: unit.hook.api@INFO: <-- install
2012-01-17 20:51:24,883: unit.hook.api@INFO: --> config-changed
2012-01-17 20:51:25,561: unit.hook.api@INFO: Updating buildbot configuration.
2012-01-17 20:51:26,811: unit.hook.api@INFO: Config decoded and written.
2012-01-17 20:51:27,406: unit.hook.api@INFO: <-- config-changed
2012-01-17 20:51:28,793: unit.hook.api@INFO: --> start
2012-01-17 20:51:30,613: unit.hook.api@DEBUG: opened 8010/tcp
2012-01-17 20:51:31,258: unit.hook.api@INFO: <-- start

On LXC, or perhaps with the newest drop of juju, the log can be found on the client at /var/log/juju/unit-$UNITNAME.log.

The order of hooks on startup is as follows:
- install
- config-changed
- start

As a result, config-changed hooks shouldn't assume that a service has been started; they should check before restarting it.

On upgrading to Precise from Oneiric, there is a problem in which /etc/alternatives/java does not get updated. See 887077. The work-around in that bug stated by pitti did not work for me. I had to manually change the link like so:
The name specified in metadata.yaml must match the directory name or juju reports the charm cannot be found.

/home/bac> ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 45 Jan 23 13:46 /etc/alternatives/java -> /usr/lib/jvm/java-6-openjdk-i386/jre/bin/java*

Notes for creating Juju Charms

Debugging notes

LXC

You can see the Juju environment in the lxc by looking (cat) in the host at /proc/PID/environ, where PID is the PID of the machine agent (ps aux | grep machine should show it). The machine configures the containers with a base juju environment.

Look in your ~/.juju/environments.yaml for the data-dir configured for your lxc. Now look in the dir. It has lots of good logs for what is going on. $data-dir/$uid-$environmentname/units/master-customize.log has some good stuff in particular.

launchpad development

yellow/Juju