alpha space is IPv4 only

[Simon Déziel]

When deploying without specifying a space, the "alpha" one is used as default. Apparently this space doesn't have any subnet associated with it but somehow, it ends up getting an address from the first subnet in another space.

$ juju spaces
Name Space ID Subnets
alpha 0
cloud 3 172.17.18.0/24
                     2602:fc62:b:1018::/64
demo 1 172.17.17.0/24
                     2602:fc62:b:1017::/64
dev 2 172.17.16.0/24
                     2602:fc62:b:1016::/64
undefined 4 172.17.20.0/24
                     2001:470:b0f8:1020::/64
                     2602:fc62:b:1020::/64

When calling get_binding(), the network.ingress_addresses contains only an IP in 172.17.18.0/24 so we could say that "alpha == IPv4(cloud)".

However, if a space is explicitly bounded to "cloud" for example, the network.ingress_address will contain both an IPv4 and an IPv6 from the right subnets.

IMHO, if this "alpha" space should inherit the subnet of another random space, it should get both INET family subnets.

Additional information:

$ juju version
2.9.11-ubuntu-amd64
MAAS: 3.1.0~alpha1

[Joseph Phillips (manadart)]

This is by design.

There is a model configuration item, "default-space", which is used as the default binding for all deployments where it is otherwise unspecified. By default, it is "alpha".

In order to accommodate legacy deployments, we do not throw an error when applications are bound to an empty alpha space, rather we treat such a situation as space-agnostic.

What then happens is that the binding information returns the preferred private address of the machine where the unit is deployed. This can only be one address and Juju's selection rules will prefer an IPv4 local-cloud address.

The solution is configure the model's default-space with one of the MAAS spaces.