<div dir="ltr">Greetings all-<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><ol><li>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.<br>(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.)</li><li>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).</li><li>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. </li><li>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).<br>For Operators, they can specify the binding of every endpoint with:<br>juju deploy --bind "admin=admin-space db=internal-space"<br>As a short-cut for the common case of wanting everything in the same space, you can just specify:<br>juju deploy --bind space<br>In bundles you can also specify bindings with a bindings stanza. eg:<br><pre>    mysql:
      charm: "./xenial/percona-cluster"
      num_units: 1
      bindings:
        access: internal-api
        shared-db: internal-api

<font face="arial, helvetica, sans-serif">There is also a shortcut in bundles by doing:
</font><pre><font face="monospace, monospace">    mysql:
      charm: "./xenial/percona-cluster"
      num_units: 1
      bindings:
        "": internal-api

</font><font face="arial, helvetica, sans-serif">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</font></pre></pre></li></ol><div><font face="arial, helvetica, sans-serif"><span style="white-space:pre">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</span></font></div></div></div>