↓Skip to main content

Unfiltered reflections on my first Juju charm

·3 mins

I just finished up my first Juju charm, designed to deploy the tiny and not-yet-useful libdep-service, which is going to become a micro-service used by pkgme-service, which exists to automatically package submissions by application developers to developer.ubuntu.com.

The charm works, insofar as it brings up a Django service that implements the API. It’s not really ready for others to use, as it doesn’t provide any interfaces and doesn’t make good use of Juju’s configuration system.

It’s very early days for me as a Juju user. The notes below are largely about problems, but I’m actually fairly optimistic that having a charm for my service will be very useful. Two big benefits so far:

  1. There’s less code than in my equivalent fabric task for deploying to EC2
  2. I can deploy to LXC on my laptop, which means a fast, clean, local, production-like environment

Anyway, on with the notes.

  • \#juju is heaps better when America is awake
  • upgrading with apt requires a lot of options, but this is quite a standard action
    • - e.g. `sudo DEBIAN_FRONTEND=noninteractive apt-get dist-upgrade -q -y` - You get this by default if you don't use sudo, and you don't have to use sudo
  • so many [things that are just warnings are marked as` ERROR`](https://bugs.launchpad.net/juju/+bug/955209), makes debugging much harder
  • perhaps this is intrinsic, but there are almost always four to six errors to be debugged at once
  • Don't use lp: URLs to fetch branches because it generates warnings. Use http://code.launchpad.net/ instead.
  • Is there a way to have a local apt mirror or something to make iterating faster?  Is this what I've got already?
  • When translating from fabric `run("cd X && Y")`, remember that fabric restores directory after `run`
    • - Use`(cd X && Y)` in bash instead, runs in a subshell
  • **ACTION:** Look up 'man 8 apt-get' for --force-yes and why it's bad
  • Long-ish iteration cycle (2-5 mins) makes it a bit slow going
    • - See also [Users not told when deploy actually completes](https://bugs.launchpad.net/juju/+bug/1015644) - Iterating with 'deploy --upgrade', watch 'debug-log', 'destroy-service', (sometimes 'bzr ci'; 'bzr push')
  • After delegating to puppet, if that fails, the `install` hook doesn't fail
  • Ended up putting the puppet stuff should be in the charm to avoid having to commit & push the branch up
  • A little bit surprised that hooks run as root.  I don't have a credible alternative to hand, but I thought that this was what we wanted to get away from with .debs.
    • - How do I run things with less privilege
  • I do server-side changes a fair bit to fix things. It's easy to forget a step when applying them back to the charm / manifest. No easy way of checking either.
  • Bouncing on this command is heaps better:`juju deploy --repository=charms --upgrade \`` local:libdep-service && jitsu watch libdep-service \    --state=started --num-units=1`
↑