I was messing around with LXD and networks and decided to try network-spaces with juju while I was going at it.
The documentation says that its not supported (@tmihoc) : Juju | Space
… but, I thought to see what would happen anyway.
So after I added the network to my lxd-cloud with a managed bridge (name: br001 and with a subnet CIDR 10.241.98.0/24 and ipv6 support), I did:
juju reload-spaces
Name Space ID Subnets
alpha 0 192.168.2.0/24
10.241.98.0/24
fd42:d264:4416:5fe8::/64
Juju acctualy picked that information up and added it to “alpha” space.
I then created a new space (br001) and moved the new subnet (only ipv4) to it:
juju add-space br001
juju move-to-space br001 10.241.98.0/24
juju spaces
Name Space ID Subnets
alpha 0 192.168.2.0/24
fd42:d264:4416:5fe8::/64
br001 1 10.241.98.0/24
juju deploy tiny-bash --bind br001
… and voila! See, the container is getting its public address (10.241.98.57) from the correct space.
But, there is a bug i think @tlm since the ipv6 address is allocated to the eth1 device inside the container. (Or, it might be by design for the fdXX::/64 addresses of ipv6 ?) Nevertheless this is the case that the ipv6 address ends up on the eth1 device.
Could this also be an effect of me having disabled the ipv6 in the lxd-host side for the default bridge (192.168.2.0/24) ?
Even if this might be “not supported”, this is great for many reasons, but also the documentation says this shouldn’t work.
Do I get this wrong - is lxd spaces supported or did I just encounter unsupported features?
The version of Juju used by the model version: 2.9.26