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 [email protected] 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 -- Mailing list: https://launchpad.net/~yellow Post to : [email protected] Unsubscribe : https://launchpad.net/~yellow More help : https://help.launchpad.net/ListHelp
