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.
In order to compile juju-core from source you’ll need to install a few dependencies. It’s easy to do with
# 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/184.108.40.206 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.
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,
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 sshonly works with the unit name, not the machine number. So to access a machine you’ll need to use
juju ssh wordpress/0instead 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-loghowever, 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!