Network Changes in 2.1 (and possible future 2.2 changes)

[John Meinel]

(sorry for the premature send)

On Thu, Feb 9, 2017 at 7:10 PM, John A Meinel <john.meinel at canonical.com>
wrote:

> 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
>

Our ultimate goal is to provide these primitives across all providers. Some
things are likely to be small enough to make it into 2.1.1 (We're hoping to
address several bugs with how spaces interact with bundles and charms on
AWS,vSphere and manually provisioned machines.) Others are more likely to
end up as 2.2 items.

As always, feedback is welcome. When things don't act the way you expect,
it may be a bug, it may be work that we haven't quite gotten to yet, or it
may just be intentional but unexpected behavior. Ideally there would be
very little of the latter, as we try to make things reliable and
predictable.

Thanks,

John
=:->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20170209/6da55ea9/attachment.html>