Network Changes in 2.1 (and possible future 2.2 changes)
John A Meinel
john.meinel at canonical.com
Thu Feb 9 15:10:38 UTC 2017
As part of our goal of giving operators and charms explicit mechanisms to
specify what they want wrt networking and be able to give reliable
operations, we've made a few changes in 2.1 that push us closer to the goal
of reliable and repeatable operations.
Most of the visible changes in 2.1 are around how we handle machines that
have more than one network interface. As a quick background, a network
"space" in Juju is a collection of subnets that are intended to be
"interchangeable" (eg have the same firewall rules, etc). The idea is that
as an Operator, you can tell us "put my database into the 'internal-only'
space", and Juju will do the work to find a machine that has access to one
of those subnets, and tell the charm about the network configuration for
the specific machine that it ends up on.
Most of the changes in 2.1 are around how we deal with applications that
are deployed into containers, and how that interacts with spaces. The key
points I believe are:
1. We are now stricter about requiring operators to inform us of what
spaces they want the application to be in. If we are about to provision a
container on a machine that has more than one space, but we do not have
information about what spaces that container needs to be in, we will treat
it as a provisioning failure, rather than guessing.
(in 2.0, any container we created would be have a network interface for
every interface on the host, thus it was always in all spaces, however that
still lead to bugs where we weren't sure which one to actually tell the
application to use, because the operator didn't specify, and Juju was left
2. In 2.0, we also would create a bridge for every network interface,
even if you never intended to create a container connected to that space.
For 2.1, we now wait to create the bridge until we see a request for a
container that is using that space. That should ultimately create a better
experience for operators. Charms that are deployed to bare metal no longer
have the overhead of going via a bridge and a network card that had to be
put into promiscuous mode (in case you add a container later).
3. For 2.2, I'd like to see us move this a step further, where any
application that would end up on a machine with multiple spaces, but does
not have a binding indicating how it should be configured would end up as a
provisioning error, instead of Juju guessing.
4. Bindings are supported on a per-endpoint bases (you can configure
mysql so that the 'admin' endpoint is accessed on a separate subnet than
'db'.) However, charms will need to be updated to support that level of
flexibility. The existing "unit-get private-address" doesn't have the
context for us to know which binding to give it, so they will need to be
updated to use "network-get --primary-address BINDING" (eg network-get
For Operators, they can specify the binding of every endpoint with:
juju deploy --bind "admin=admin-space db=internal-space"
As a short-cut for the common case of wanting everything in the same
space, you can just specify:
juju deploy --bind space
In bundles you can also specify bindings with a bindings stanza. eg:
There is also a shortcut in bundles by doing:
Ultimately we'd probably like a better syntax around a default binding,
but this syntax is compatible with 2.0. The real difference is
we're more likely toenforce correct values in 2.1.
So while a bundle may need updating, after updating it should be
compatible with 2.0 and 2.1
There are some aspects that we were not able to get to in time for 2.1. Our
ultimate goal is to provide these primatives across all
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Juju-dev