Juju feedback from the Launchpad Yellow Squad

[Graham Binns]

Hello Juju people (Are we supposed to call you priests? Shamans?
Anyway...)

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.


Feedback
~~~~~~~~

 * 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
     this.
 * 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
   wordpress/0`.
 * 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
   labour-intensive.
 * 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
   anyway).
 * 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.
 * 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
   tests.

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.