Juju feedback from the Launchpad Yellow Squad
mark.mims at canonical.com
Wed Feb 15 19:09:47 UTC 2012
On 02/15/2012 11:30 AM, Graham Binns wrote:
> 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.
Great feedback! Thanks for taking the time to write it up.
> * 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
awesome... can you please add this to charm-helpers (see below)?
> 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
> (https://juju.ubuntu.com/docs/charm.html#hook-environment) was
> 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
> production usage.
We're currently trying to collect such helpers into packages like
They're in a ppa:charmers/charm-helpers built from lp:charm-tools. We
definitely need to make this more visible in docs/faqs as you mention
above. We've been sort of letting best-practices for charming grow
organically to date, but it's time to cut some clear decisions and
recommendations for this before the precise release.
> * 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
This is currently being integrated into charm-tools... 'charm test
but it eventually belongs in a juju CLI plugin IMO.
> 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.
Mark Mims, Ph.D.
mark.mims at canonical.com
More information about the Juju