yellow team mailing list archive

[Graham Binns <graham@xxxxxxxxxxxxx>]

Hi chaps, below is the draft email to the juju list with our feedback.
Please let me know of any corrections / additions / subtractions you
wish to make.

There are some items that I haven't been able to parse or understand
and so couldn't paraphrase. If their authors could sort me out with a
more straightforward version of each one, I'd be grateful.

Cheers,

Graham

===== DRAFT BEGINS =====

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


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@xxxxxxxxxxxxxxxxxxx or in #launchpad-yellow on Freenode.


ITEMS FOR YELLOWJACKETS TO EXPLAIN
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 * Doc: 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.
 * Doc: recommend charms for review, such as mysql for multiple slaves.
 * The wrapper script functionality would appear to be includable in
   the base juju command


===== DRAFT ENDS =====
-- 
Graham Binns | PGP Key: EC66FA7D
http://launchpad.net/~gmb