Network spaces and LXD

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

Screenshot from 2022-05-03 00-14-30

… 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          

Then I tried: https://discourse.charmhub.io/t/advanced-application-deployment/1061#heading--deploying-to-network-spaces#heading--deploying-to-network-spaces

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

3 Likes

@manadart Ping for space support knowledge.

Spaces are supported on LXD insofar as LXD can provision on subnets that you carve into spaces.

We use the LXD network API to detect subnets that are bridge networks. This may pick up subnets not managed by LXD. On my local machine for example, it detects my Docker bridge and others.

This patch was the last in a series that added the support.

@tmihoc that means that the documentation is outdated on this. It says that its not supported.

Thanks for following up on this! I’ve updated the doc to include LXD and made plans to clarify better tomorrow. PS This doc has a bunch of other issues. Working on them.

1 Like