Juju feedback from the Launchpad Yellow Squad

[Mark Mims]

On 02/15/2012 11:30 AM, Graham Binns wrote:
> 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.
Great feedback!  Thanks for taking the time to write it up.

>
>
> 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).
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
>     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.
We're currently trying to collect such helpers into packages like 
charm-helpers-$language.
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
>     tests.
This is currently being integrated into charm-tools...  'charm test 
-e$juju_env $charm_name'
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.
>

otherwise, +1

-- 
Mark Mims, Ph.D.
Canonical Ltd.
mark.mims at canonical.com
+1(512)981-6467