I agree there needs to be a vertical agreement on what is what. I do think
we have opposite views on what 'configured NIC' means.

For instance, I'd argue that NIC is configured even without an IP. I would
argue that NIC is just a device, that can have, but doesn't have to,
attached layer2 properties (MTU settings, VLAN ID, etc). Then it can also
have layer 3 properties - an IP address. I would also argue that MAAS
doesn't say that a NIC without an IP is an unconfigured NIC. Not only is
such NIC available on the system, but it also has layer properties - VLAN
ID, MTU. MAAS does some work to make this happen, it configures it. IMHO,
unconfigured NIC would be a NIC without an IP, but also without MTU
settings and VLAN ID and also a NIC that is 'DOWN' (no link-layer). Such
NIC would be unusable by any charm unless the charm goes to an extent of
managing the NIC.

Fabrics and spaces go well in line with this - NIC connected to fabric has
layer2 properties, NIC connected to a space has layer3 properties. Problem
with both Landscape and LXDs with multiple interfaces is that they both
require some layer3 properties to figure out layer2 device. In case of LXD,
this is not a hard requirement, rather a nice way for juju to figure out
which IP to assign to the container. Neutron gateway charm is a bit stupid
about it, it just uses whatever you give it. However, in an ideal world,
one should be able to say 'put neutron-gateway to a machine that has a NIC
attached to that fabric'. Question that we have then; is any NIC attached
to that fabric a candidate, or only those NICs that have only layer2
properties from that fabric, ie. no subnet declaration?

I think juju should be aware that a NIC is exposed only with layer2
properties, but it should also know what layer3 properties are possible on
it. This is why in RC1, attaching a subnet to a NIC gave juju opportunity
to figure out which layer3 properties are available on the NIC. It used
that to create a bridge, connect a container to it, and assign an IP to
that container from that subnet. With RC2 we bring in hard requirement of
having an IP on the host to create a bridge for containers.

On Tue, Oct 4, 2016 at 6:26 AM Richard Harding <email address hidden>
wrote:

> After additional discussions we came to the conclusion that Juju should
> respect the same ideas that MAAS does. In MAAS, a nic is not
> "configured" until it has an IP address. Setting a fabric, or even a
> subnet, does not return that as "configured" in MAAS. It's still
> unconfigured.
>
> Juju will not bridge all "configured" interfaces. If we want to question
> the definition of configured then we need to address it in our complete
> stack so that we're consistent and have a reasonable explanation of what
> users can expect as they put together our tools into a final solution.
>
> The behavior seen in RC2 is expected, and we admit is not ideal for all
> cases, but we decided that it was better to be consistent and
> predictable and to work to get layer 2 support into Juju so that it can
> properly handle the additional cases that folks are looking to put into
> play.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1627037
>
> Title:
>   rc1 bridges all nics, breaks neutron-gateway
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1627037/+subscriptions
>
-- 
Ante Karamatić
<email address hidden>
Canonical