Exploring Juju with Project Calico

Installing OpenStack is non-trivial. You need to install a large number of packages across a number of machines, get all the configuration synchronized so that all those components can talk to each other, and then hope you didn’t make a typo or other form of error that leads to a tricky-to-debug misbehaviour in OpenStack.

For this reason there has been a proliferation of systems that make it easier to install OpenStack: think Fuel, TripleO, Packstack, and more. These systems are targeted at different users and fall in different places on the sliding scale of “ease of use” to “control”. Some are graphical, some aren’t. Some are highly prescriptive, some aren’t. Some allow third-party projects, some don’t. They’re all interesting, and for anyone who plans to plug into OpenStack they’re all tools you want to integrate with.


One of our favourite tools comes out of Canonical, and it’s called Juju. Juju is a tool that allows you to deploy complex and scalable applications in a service-oriented manner. Your application as a whole is deployed by deploying a number of services and linking them together in a well-defined manner, such that they correctly determine what their configuration and run-time state needs to be. The user deploying this application doesn’t have to care whether each service lives on its own machine or not: Juju handles all of that for them. Instead, they simply put in the pieces they need, configure them, and go.

At this point, people usually show you the Juju web GUI, which tends to look like this:


Using this you can see the way Juju thinks about application deployment. Each little box is a ‘charm’, a self-contained unit that provides and consumes a number of services. Each service a charm provides or consumes is encapsulated  by what Juju calls a ‘relation’. Services consume and provide ‘relations’, and if one of your service provides a relation another of your services consumes, you can link the two together.

Relations are the core motivator of Juju, and they’re a little complex. They are M-to-N relationships: multiple charms may provide a relationship, and multiple charms may consume them. In some cases this doesn’t make much sense (who needs multiple SQL databases in one application?), but in other cases it’s perfectly natural.

Each relation is more than just a link: they carry data. This allows a Juju deployment to become extremely reactive. This information might be useful to tell a charm more specific information about a service (for example, is it connected to a PostgreSQL database or a MySQL database?), or it might tell a charm things that it needs to know to correctly configure itself (like what version of an API is being exposed), or it might be used to share per-instance information (such as a shared seed for a RNG). It also makes it possible to centralise configuration: one charm can own a piece of configuration information and pass it, via relations, to other charms that need to know about it.

While the Juju GUI is a nice marketing tool, it’s not the way you’ll mostly use Juju. Instead, you’ll use its flexible command-line tool. This lets you deploy and configure charms really easily. It also lets you see a nice textual view of your deployment. For example, this is what it shows for the Calico ACL Manager charm:

  charm: local:trusty/calico-acl-manager-0
  exposed: false
    - neutron-calico
    - neutron-api
      agent-state: started
      agent-version: 1.20.14
      machine: "1"
      - 9905/tcp
      - 9906/tcp
      public-address: calico-vm12.datcon.co.uk

This view is normally much longer than this, containing multiple charms deployed over multiple machines. Nevertheless, it’s a good detailed view to look at, and it has the added advantage of being entirely in YAML format, making it machine-parseable. Always a good choice!

Juju, OpenStack, and Calico

Juju’s original remit was to deploy applications into cloud IAAS services: things like AWS or Rackspace Cloud. This is an extremely useful goal, and Juju does it well. But it has a secret superpower up its sleeve. When combined with another Canonical product, Metal-as-a-Service (MAAS), Juju becomes able to install services onto physical hardware, treating each physical server like a virtual cloud server. This superpower opens up an exciting possibility for large applications like, for example, OpenStack, to be installed via Juju! Doing this makes it possible to install OpenStack relatively easily.

More importantly, because the charms are modular, it makes it possible to easily remove one part of OpenStack and replace it with another. One of those things you might want to replace is your Neutron plugin: possibly with a fancy new plugin like Calico!

For that reason, a few weeks ago we began work on developing a set of Juju charms that will let you deploy OpenStack with Calico using Juju. With these charms it becomes really easy to get OpenStack+Calico off the ground right away. There’s minimal configuration, just grab the necessary component charms and you’re flying. Or save yourself some time and grab a deployment bundle like the one I posted on the Calico mailing list.

Once your system is up and running it becomes really easy to scale it out, too. Need another compute node? Tell Juju to add one: it’ll grab a new machine, install it and configure it. Calico will dynamically spot the network has changed and update its configuration accordingly. Scaling even bigger? Add a BIRD charm to your deployment and tie it to the neutron-calico charm, and then Calico will reconfigure itself to stop using a BGP mesh and start using BIRD as a route reflector instead, like magic. No configuration, no buttons to push: the Calico charms make the best decisions given the resources available to them. Simple.

The Calico charms are available now, on Launchpad. They are open source, just like the rest of Calico, and you can try them out today. Please be aware that they’re currently beta versions: try them out, but do report to us any bugs you encounter! Note also that deploying OpenStack using Juju requires several charms working together: I recommend checking out the bundle linked above to see exactly how to do it.

Over the next few weeks we’ll make some follow-up posts, talking in more depth about how we built these charms and how you can get started building them as well. We’ll also provide some tips on ensuring that your Juju-built OpenStack networking is set up correctly for Neutron, rather than the default Nova.

We’re excited to be part of the Juju community, and we’re looking forward to seeing what we can build together.

Cory Benfield

Cory Benfield

Cory is a Software Engineer at Metaswitch Networks. He's an active Python open source developer: outside of Project Calico, he's a core developer in Python's requests library, Python's urllib3 library, and a number of others. He is also the maintainer of hyper, an open-source Python HTTP/2 stack. He doesn't currently own any cats, though he loves them from a distance.

You Might Also Like

EKS, Bottlerocket, and Calico eBPF

Introduction Bottlerocket is an open source Linux distribution built to run containers securely in scale by Amazon, it is uniquely tailored to improve stability and performance with a great focus

Read More

What’s new in Calico 3.16

We’re very excited to announce Calico v3.16.0! This release includes the eBPF dataplane going GA, the addition of Windows support for Kubernetes, and BGP communities support. In addition, this release

Read More

Join our mailing list​

Get updates on blog posts, new releases and more!

Thanks for signing up!