Juju feedback from the Launchpad Yellow Squad
graham at canonical.com
Wed Feb 15 18:30:51 UTC 2012
Hello Juju people (Are we supposed to call you priests? Shamans?
We on the Launchpad Yellow Squad have been working on producing a couple
of Charms for buildbot (one for the buildmaster, one for buildslaves)
over the last few weeks. Now that we're ready to submit our Charms to
you for review, we also wanted to put together some feedback about our
experience with Juju and with developing Charms. Hopefully it will be of
some use to you.
* The current Juju Docs are excellent, but they still have significant
holes in them. We've spent quite a while trying to get Juju to fit
into our collective brain, is a hard but valuable goal. A couple of
items missing from the documentation that would be worth including:
* Your local terminal needs to be in UTF8 (not by default on
my Precise machine for some reason! ANSIX3.4-1968) or else byobu
will render the bottom line problematically.
* There are several cases in which the best way to learn something
is to look at other Charms (e.g. MySQL does a nice job of handling
multiple slave services deployed from the same charm but with
different configurations). There should be an FAQ or similar
pointing Charm developers at good practice example Charms like
* We spent quite a while doing a lot of work in the config-changed
hooks before realising that this wasn't the most efficient way to do
things and was prone to breakages (because Juju doesn't keep track of
what's changed for you; we implemented our own config caching as a
result). Charm authors should be encouraged to use the install hook
primarily, with "deploy --config" to set config options.
* The one-way communication aspect of relation-set was surprising (so I
can relation-set foo=bar but I can never find out later on what I've
already told a relation about config options).
It would be great if there were a utility to retrieve whatever had
been sent to a relation. This would also be a nice way of caching
things for Charms :).
* Juju should allow service-destroyed hooks: bug 932269
* Optimization in ec2 (and presumably Canonistack) of reusing machines
is painful, especially without any kind of "destroy service" hook.
There's no way to ensure that the previous Charm has cleaned up after
itself, which gets particularly problematic when you deploy the same
charm to the node later on (because if the old one hasn't cleaned up
properly, directories may exist that shouldn't and ports may be bound
to that should be free).
* Juju should provide a way to reset a node without tearing down the
environment (see above under optimisation in EC2, too). It would be
nice to ensure that a node is bounced before a new charm is deployed
on it. Something like `juju reset-machine 1` or `juju reset-unit
* The upgrade-charm command seems like it needs to work even if service
is not active. At the moment you have to have an active instance of
the service in order to upgrade the charm, or else you have to
destroy-environment and then bootstrap again, which is
* Being able to do a relation-set within a config-changed is important
(we understand this is a known issue, but it's worth mentioning
* Using environmental variables for identifying the other end of a
relation in relation-changed
surprising, especially given that you can use relation-get to get
things like private-address from relation-get.
* Juju should have a way to share code across Charms, like helpers.
bzr does not provide something like svn-external, unfortunately, so
this might need to be a build step of some sort. We've got around
this by using symlinks during development, but that's no good for
* Running juju-log as a non root user (at least as buildbot) hangs.
* It would be nice to be able to have the default environment set via
an environment variable. That way I don't have to keep editing
.juju/environments.yaml ("default") or using -e for every command
as I switch between lxc, ec2 and canonistack.
* The above point is also important for testing. Since our Charms
should be as environment-agnostic as possible their tests need to
pass on all environments. It would be great to be able to run tests
with, say, JUJU_ENV=ec2, and then =lxc, and then =canonistack rather
than having to edit ~/.juju/environments.yaml.
* In order to run tests, there's a test wrapper (as proposed by Clint,
IIRC). There seems to be no reason that this wrapper's functionality
shouldn't be included in the main juju executable; developers
shouldn't have to jump through hoops just to be able to run their
That's about it for now. If you've any questions about any of the things
we've mentioned below, please don't hesitate to ask. You can reach us at
yellow at lists.launchpad.net or in #launchpad-yellow on Freenode.
More information about the Juju