Network Changes in 2.1 (and possible future 2.2 changes)

[John A Meinel]

Greetings all-

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
   to guess.)
   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
   --primary-address db).
   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:

       mysql:
         charm: "./xenial/percona-cluster"
         num_units: 1
         bindings:
           access: internal-api
           shared-db: internal-api
   There is also a shortcut in bundles by doing:

       mysql:
         charm: "./xenial/percona-cluster"
         num_units: 1
         bindings:
           "": internal-api
   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...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20170209/64e0befc/attachment.html>