For fun and profit I tried out juju today. Following basically the tutorial to test it out with vagrant, I’ve created a Vagranfile to load several trusty-amd64-juju boxes to juju on them.

Color me not impressed.

  • The juju image flavor is twice the size (+300MB) of the normal trusty vagrant image.
  • When provisioning the trusty-juju box, it downloads even more stuff from the internet to finish the installation.
    • … using a progress bar that totally breaks in vagrant (one line per character, shows time to finish and current d/l speed).
    • … 228MB, if I read this correctly.
    • … deploying to an lxc container within the virtual box.
    • … using an internal non-routed IP for this container.
  • Adding nodes to the main juju host (using the normal trusty vagrant image) fails since juju configures a proxy for apt’s http method, which is running in a container on the juju host. Since the container is using a local bridge, it is not reachable from the new box.
    • fixed the communication problem by manually adding the appropriate route on the clients.
    • … only to find out, that the squid is – of course – configured to only allow access from the lxc network. Added more sed to Vagrantfile. Fixed.
    • … only to find that the squid has “slight” configuration problems and fails to properly forward files from the mirrors. More sed fixes.

    • … except that this was no immediate squid problem, but some weird DNS issue that went away by itself after a few tries.

      Heavy voodoo here. I can’t even believe you are reading this. Are you crazy? Don’t even think about adjusting these unless you understand the algorithms in comm_select.c first! – the squid docs about dns parameters

At this point I had a mostly working juju main box and a few added agents running.

Phew!