Compiling Juju and the local provider

I wanted to really quickly publish what I’ve done to compile different versions of juju-core and use them in a sane fashion and outline really quickly how the new local provider works. If you haven’t heard already, 1.11.3 was just released with initial support for a local provider. First, if you’re looking to install juju-core, it’s really easy to do! You can grab the latest development releases from ppa:juju/devel. If you’re here for local provider, just scroll down a little further after installing 1.11.3. If you’re impatient like I was, or you really want to compile from source, you can journey down the relatively straight forward road of compiling juju-core using go. I strongly recommend using the PPA, releases are frequent enough that unless you really want to test tip features you don’t quite need to compile from source.

Compiling

In order to compile juju-core from source you’ll need to install a few dependencies. It’s easy to do with apt-get

# Latest juju-core requires golang-go > 1.1 which is available in this PPA
sudo add-apt-repository ppa:james-page/golang-backports
sudo apt-get update
sudo apt-get build-dep juju-core
# This last step is just for good measure, build-dep should catch
# everything but I'll err on the side of safety
sudo apt-get install mongodb-server golang-go lxc libcurl4-gnutls-dev mercurial mongodb bzr
sudo service mongodb stop

Once you have all the dependencies installed and have stopped the default mongodb server, you’ll need to create a path where you want to install the juju-core source and binary. This will be your GOPATH. I like to keep everything in one directory, so for me ~/.juju/ is where I place things. However, this path can be anywhere on your system.

export GOPATH=~/.juju/1.11.3.1
mkdir -p $GOPATH

Finally, fetch and build the source.

go get -v launchpad.net/juju-core/...
go install -v launchpad.net/juju-core/...

Once complete, verify you indeed have compiled juju by running $GOPATH/bin/juju version. If you get a version output, then you’ve successfully downloaded and compiled juju-core! At this point you can either add $GOPATH/bin to your path, or you can use update-alternatives to have juju point to the compiled version (if you’ve installed the proper juju meta package, or do not have any PPA versions installed). In the event of the latter, you’ll want to do the following:

sudo update-alternatives --install "/usr/bin/juju" "juju" "$GOPATH/bin/juju" 25
sudo update-alternatives --config juju

In the selection screen choose the version you wish to use.

Local Provider

I am really really excited about this feature. The juju-core devs overall really deserve a round of applause, juju versions > 1.0 have been getting faster and better with each release. With new versions landing far quicker than before with more features it’s really shaping up to be a great product. With the local provider having just landed, it’s my opinion that juju core has surpassed juju 0.7 as far as feature parity and usability. With the exception of one feature, juju core now does everything as well as 0.7 with most things out performing. If you’ve compiled from source or installed juju-core > 1.11.3 from the PPA then you’ll have access to the local provider. To verify you can run juju init, if you see an example local provider in the output then you have access to the local provider.

If you haven’t already downloaded the dependencies, you’ll need to install mongodb-server and lxc

sudo apt-get update
sudo apt-get install mongodb-server lxc
sudo service mongodb stop

Configuration for local provider is really straight forward. Here’s the example output from juju init and then the bare-minimum needed to get local provider working

  local:
    type: local
    admin-secret: 713f68c039072edf73f4a31b69534778
    # Override the directory that is used for the storage files and database.
    # The default location is $JUJU_HOME/.
    # $JUJU_HOME defaults to ~/.juju
    # root-dir: ~/.juju/local
    # Override the storage port if you have multiple local providers, or if the
    # default port is used by another program.
    # storage-port: 8040
    # Override the shared storage port if you have multiple local providers, or if the
    # default port is used by another program.
    # shared-storage-port: 8041

This is all that’s needed though

local:
    type: local
    admin-secret: <strong random admin password>

Once you’ve got your ~/.juju/environments.yaml updated with the new environment, bootstrap!

sudo juju bootstrap -e local

When using the local provider, bootstrap and destroy-environment require sudo access. This is because the local provider turns your host machine in to the “bootstrap” node by running an instance of mongodb as the state server and a second job as the orchestration agent. After you’ve bootstrapped you can begin deploying units as you would any cloud using juju boostrap and the other juju commands. The first deployment will take a bit of time as the Ubuntu cloud image is downloaded (~210MB) and cached locally. Subsequent deployments and bootstraps will use this cached file and should be a bit quicker. As this is a first cut of the feature, I’m told improvements to the speed of deployments using local provider are to be expected in the future. Comparatively, I’ve been able to work much faster on charm development as the local provider is quick, cheap, and easy to use.

Local provider caveats

At this time there are a few caveats with the local provider that people should be aware of:

  • juju ssh only works with the unit name, not the machine number. So to access a machine you’ll need to use juju ssh wordpress/0 instead of something like juju ssh 1
  • The mongodb version available in precise won’t work with the local provider. There’s a bug open and hopefully a fix will land in the PPA that patches precise’s mongodb with the version from raring. So if you’re on precise and are trying the local provider but can’t bootstrap this is likely the issue.
  • Not so much a caveat, rather a feature, still no juju debug-log however, you can access the logs from your machine locally by navigating to the log direction in your data-directory (defaults ~/.juju/<environment-name>/log, so if the environment name is local: ~/.juju/local/log). There you’ll find both machine and unit logs. Unit logs will be the logs to each respective deployed unit.

If you find any bugs during your use of the local provider, please file them on LaunchPad; otherwise, if you have any questions you can always ask them in the usual place: IRC, Mailing List, and Ask Ubuntu!

  1. Torino

    0
    down vote

    favorite

    I’m working with MAAS and juju. And I use 6 nodes for Openstack.
    Everything goes good! But when I try to upload ubuntu-cloud-image there are errors.

    Thu Sep 26 09:43:43 UTC 2013: ====== extracting image ======
    Warning: no ramdisk found, assuming ‘–ramdisk none’
    kernel : oneiric-server-cloudimg-amd64-vmlinuz-virtual
    ramdisk: none
    image : oneiric-server-cloudimg-amd64.img
    Thu Sep 26 09:44:01 UTC 2013: ====== bundle/upload kernel ======
    failed to upload bundle to images/oneiric-server-cloudimg-amd64-vmlinuz-virtual.manifest.xml
    failed: euca-upload-bundle –bucket images –manifest /tmp/cloud-publish-image.reLvSN/oneiric-server-cloudimg-amd64-vmlinuz-virtual.manifest.xml
    S3_URL not specified. Trying http://localhost:8773/services/Walrus
    Checking bucket: images
    [Errno 111] Connection refusedfailed to upload kernel

    How can I fix it?

Leave A Comment?