Quantcast
Channel: Planet Ubuntu
Viewing all articles
Browse latest Browse all 12025

Marco Ceppi: Compiling Juju and the local provider

$
0
0

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

sudoapt-get updatesudoapt-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 safetysudoapt-get install mongodb-server golang-go lxc libcurl4-gnutls-dev mercurial mongodb
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.

exportGOPATH="~/.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. In the event of the latter, you’ll want to do the following:

sudo update-alternatives --install"/usr/bin/juju""juju""$GOPATH/bin/juju"25sudo 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

sudoapt-get updatesudoapt-get install mongodb-server lxcsudo 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 -elocal

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!


Viewing all articles
Browse latest Browse all 12025

Trending Articles