should be a way to specify space binding for maas "unconfigured" (layer-2) interface

[Larry Michel]

Some network charms have requirements that a particular interface be connected to a specific network and that the interface be left unconfigured.

When using "data" binding for the neutron-gateway charm and deploying bundle with Juju 2.1-beta4-xenial-amd64 and MAAS Version 2.1.3+bzr5573-0ubuntu1, having the interface with a subnet associated with "data" space and unconfigured caused the charm to fail to install because it could not access network config for the interface on the OS. But in this case, it is a valid scenario for the interface to be left unconfigured and we should not see the error.

Also refer to bug 1659360.

[John A Meinel (jameinel)]

Supporting unconfigured interfaces is something that we do want to support. I would think we already have a bug about this, but maybe it was only a road map item. The charm had a workaround for it in the past (IIRC white listing MAC Addresses in the charm config), which is absolutely a workaround for us not having the right pieces modeled to expose it properly. Did 2.1b4 break the existing workaround or is it that you were hoping unconfigured space support was already implemented?

[Anastasia (anastasia-macmood)]

As per comment # 5, we most certainly want to implement unconfigured space support. However, with 2.2 timeline and our current capacity, it will not be addressed in 2.2x.

I am removing it from milestone.

[Larry Michel (lmic)]

@John sorry I had not seen your earlier question. This is for new enablement of bindings in our bundle. So we don't know how the workaround worked prior to hitting this issue.

[Tim Penhey (thumper)]

Changing the tag name as this isn't a blocking bug, but instead a requested feature.

[Peter Sabaini (peter-sabaini)]

Just as a data point, I'd need this for a bit diff. usecase; for a cloud that calls for a publicly accessible api which we'd like to put in containers. We only have a small subnet available for that, and to save on ipaddress we have to leave the metal hosts configured with mode=link_up; only giving the actual containers ipaddress in the spaces subnet.

[Trent Lloyd (lathiat)]

As part of the implementation for this, currently charms often need to get the network interface related to an IP. Currently they use the network-get charm command to get the IP of the space, but then have to figure out what interface that IP is on manually. Ideally the charm API would be expanded to specifically give the interface.

Having said that there is a trap here when things change after deployment, by either juju or the system administrator. Right now juju or MAAS won't let you change network interfaces after deployment so manual changes might be made which juju may or may not know about.

On the juju side, a case it knows about is when an interface is moved to be a bridge, e.g. when a container is deployed on that interface. That can happen during inital deploy, but could also happen much later if a container was deployed for the first time.

Just some thoughts.

[Trent Lloyd (lathiat)]

There is an additional security argument for this feature.

Right now, if you want to deploy a container onto a space, that space must be configured with an active IP address on the metal host.

You can configure an interface in MAAS with the space defined but the IP unconfigured. In this case, while the interface and it's MTU will be written to the interfaces file, juju will not recognize the host as having an interface on that space and deployment of a container will fail.

It is completely possible to still create a bridge on the interface and deploy the container in this configuration, without having an IP on the host, however juju does not know how to do so.

Peter Sabaini's comment from 2017-05-31 argued that we want this same behavior to save IP addresses on the (possibly small) public subnet. But we also want this behaviour so that the metal host (often with sensitive services such as nova-compute or ceph-osd) are not exposed to a public internet subnet unexpectedly.

This has been a real issue in real deployments, public routable IPs are assigned to host only for the reason of connecting the public-api space in containers. This has resulted in the unexpected exposition of sensitive services to the public internet. There is no simple way currently to implement a firewall for such cases.

In MAAS environments we have no security groups or automatic firewalls in many cases to work around this issue.

If we need to move this use case into a separate bug, let me know. It's a bit borderline as it's closely related but technically is a different use case to wanting a raw interface to use for other purposes.

[Peter Sabaini (peter-sabaini)]

subscribed ~field-medium as we're hitting this again

[Peter Sabaini (peter-sabaini)]

Subscribing field-high as we have clouds running out of ipaddr

[Drew Freiberger (afreiberger)]

Agree with Trent and Peter, MAAS concept of spaces is L2, but currently juju concept of spaces is L3. While an L2 space doesn't make sense for charm use in the manner of private_address(binding_relation_name), it does make sense for subordinate use and network interface pass-through to OVS/other L3 management layer plugins.

[Ryan Beisner (1chb1n)]

This seems like it woudld require re-engineering of a Juju feature/primitive in order to properly address. I think it would need to be planned development cycle work, not break/fix bug work. As such, I'm not sure anyone can put a Field SLA on it. I'll take it to the next Juju/OpenStack engineering cross-team, however, to confirm.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.