Juju feedback from the Launchpad Yellow Squad

[Kapil Thangavelu]

Greeting Graham.

Excerpts from Graham Binns's message of Wed Feb 15 13:30:51 -0500 2012:
> 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.
> 

Awesome, thanks for the feedback, its great to hear about user experiences and 
how we can improve juju. 


> 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.

What sort of juju interface would be helpful for changes and why? Afaics its a 
fairly trivial thing for a charm todo, but if its a common enough use case, then 
juju should accomodate it. Could you clarify the usage that needed this?

Ideally, charms should be able to deploy with reasonable defaults even sans 
config at deploy time. That doesn't apply to all charms though, but its a good 
default.


>  * 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 :).

Could you explain this a bit more, how is it one-way, you can use relation-set, 
and retrieve values set with relation-get. 

 $ relation-get key $JUJU_UNIT_NAME

currently unit name is supplied by the default value of the $JUJU_REMOTE_UNIT in 
the hook.


>  * Juju should allow service-destroyed hooks: bug 932269

the 'stop' hook is the equivalent for a unit: bug 872264

>  * 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).

reuse of a machine is problematic regardless of a stop hook. we'd have to 
promote lxc everywhere to get towards this. A container per machine always would 
suffice for reuse sans incurring too many networking challenges (forward all).

>  * 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`.

this is basically the reuse case restated. unless the charm is deployed with 
lxc, there is no clean reuse possible, as the charm is effectively a binary 
scribbling on the machine as root. a cleanup point like a `stop` hook can allow 
for some cleanup for a well behaved charm, but its not a pancea.

>  * 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.

juju resolved allows for manually clearing error states and moving a unit to the 
started state. its intentional that upgrade only proceeds from a known 
good state, charms contain arbitrary logic and can fail in arbitrary ways. if 
the service unit is not in a good state, juju provides the tools for a human to 
intervene.

>  * 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).

ack.

>  * 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.

surprising because? relation-get can get data from either end of the relation.

>  * 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.

projects like charm-tools and jujuitsu provide for some reusable tools. Beyond 
that a charm is free to distribute and install common code via any mechanism, 
ubuntu packages, language specific packages, tarballs, etc.

>  * Running juju-log as a non root user (at least as buildbot) hangs.

That's a bug, it should timeout on the socket 'owned' by root.

>  * 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.

sounds good.

>  * 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.
> 

The testing story and tooling is still evolving. Part of the purpose of the 
wrapper is to encode variablility into package origin, so the runner can run 
against its own selection of charms. its not clear why this would be beneficial 
to have as part of the juju command.

> 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.
> 

Thanks again for the feedback.

cheers,

Kapil