Juju feedback from the Launchpad Yellow Squad

Gary Poster gary.poster at canonical.com
Wed Feb 15 21:23:46 UTC 2012

On 02/15/12 15:18, Kapil Thangavelu wrote:
> 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.

Our point is not that juju does not support something.  It does 
everything we need in this regard (well...see below for a suggestion, 
but it's very much a nice-to-have).

Our point is about best practices for charm writing, or at least for 
first-cut charm writing.

It can be easier and saner--and, importantly, easier to write automated 
tests--if you declare that your charm primarily supports setting things 
up via initial configs.  Only certain changes are available 
subsequently.  Maybe none are.

This limits the various states you have to handle.  It can let you 
provide immediate feedback to a user if the requested state is insane or 
broken. It can limit the tests you have to write for a basic feeling of 

Moreover, we think that charms that follow this pattern will be "good 
enough" for the common case.  People who write their first charms maybe 
should be encouraged in this direction.  We wish we had gone this way. 
It would have been simpler and faster.  We would have identified early 
on the config that we wanted to be able to be dynamic, and made 
everything else frozen initially.  Really, adding the rleationships is 
the primary bit of dynamism that we needed/wanted.

The only thing that I can think of that juju could do to help this would 
be to allow a setting of "initial-config-only" for a given config name. 
  If the name were not provided initially, juju would refuse to start 
the charm; and if the name were set after start up, juju would refuse to 
send it, with a helpful error message.

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

Yes, thank you.  I replied to this separately, after our discussion on IRC.

>>   * Juju should allow service-destroyed hooks: bug 932269
> the 'stop' hook is the equivalent for a unit: bug 872264

Ah, good to know.  Does juju destroy-service fire the stop hook on all 
the units?

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

Note that lxc-everywhere for us would not work, because we need to be 
able to run lxc in our charmed services, and lxc does not support 

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

This is the use case we are talking about:

[begin developing FOO charm]
juju bootstrap
juju deploy FOO
[discover that our FOO charm is broken]
[fix FOO charm]
juju destroy-service FOO
juju deploy FOO
[oops! I forgot to upgrade the charm but I want it to be new when I 
deploy the service again! AIUI, the charm is cached, presumably on the 
central zookeeper box.  Darn...I have to deploy the service and then 
resolve it and then upgrade it, or just destroy-environment]

So, we want upgrade-charm to work when the service is down. 
Alternatively and probably even preferable to upgrade-charm working when 
a service is not active, "deploy" would always resend the charm, or at 
least check for changes and send it conditionally.

Maybe our collective memory is wrong that juju (the zookeeper box?) has 
the old charm cached and does not automatically refresh on an attempt to 
redeploy, but that's our impression, and that's what this is about.

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

This comment is actually about the fact that some interesting relation 
data is exposed via environmental variables, and some is exposed using 
relation-get.  Making it uniform would be nice and less surprising. 
Specifically, doing it in relation-get would be nice because then you 
can document the special names in the help/man text.

Concretely, I can say "relation-get private-address".  Why can't I use 
"relation-get private-unit-name" (== $JUJU_UNIT_NAME)?  "relation-get 
private-relation-name" (==$JUJU_RELATION)?  "relation-get 
private-remote-unit-name" (== $JUJU_REMOTE_UNIT)?

I'm obviously making up and extrapolating a "private-" namespace 
convention idea within relation-get, for values that juju provides 
itself.  That's for purpose of argument.  Maybe there are better 
conventions and names, but hopefully the point is clearer now.

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

As I mentioned to Mark, packages are problematic when developing. 
Tarballs are less heavyweight but still problematic (you have to have a 
place to share them).  A lightweight way to say "get this other branch 
and make it available before you run install (where I will start to 
import code)" is what I want.

Perhaps the following would be a framework, or at least a straw man, for 
what I think ought to be there.

  * Juju lets charms simply and easily declare additional deb 
repositories (e.g. PPAs) and packages that should be installed before 
the charm runs.  (Extra points if the mechanism allows charms to let 
these values be added to or overridden by deploy-time configuration.)

  * Language specific packages provide solutions for doing the 
lightweight development we want.  For instance, perhaps a 
Canonical-provided set of packaged charm helpers depends on bzr and 
includes helpers to get files and branches from bzr installed within the 
hooks directory.  At the top of an "install" hook you could import the 
Python helper file, run the "get the code" helper to get another file 
from bzr, and then import it.

Relatedly, could you point me to jujuitsu?  Googling for "juju jujuitsu" 
and other variants did not bring it to me.

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

Cool.  Would you like us to file it?

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

Thank you.


More information about the Juju mailing list