Comment 4 for bug 1940843

The charms in the OpenStack charms collection are not tested with Fan Networking enabled within Juju and this is outside the bounds of what is known to work and have been tested. I will evaluate this bug from here forward as a wishlist item/feature request to support Fan Networking in the charm.

Generally speaking, the charms use the juju network spaces to influence which interface the charm will configure for communication methods.

In the case of fan networking, juju does not allow moving the overlay fan network to a different space and considers it in the same space as the underlay network. As such, the overlay and underlay networks are part of the same logical space.

Attempts to move it result in:

$ juju move-to-space database 252.0.0.0/8
ERROR cannot update space "database": subnet "252.0.0.0/8" is a fan overlay of "10.5.0.0/16" and cannot be moved; move the underlay instead

More analysis later, but the code uses the network-get --primary-address <relation> which does not return secondary interfaces (such as fan-networking) here. Additionally, none of the network-get calls (aside from a bare network-get --format yaml <relation>) will return the secondary interface. In this scenario, since Juju is aware that there are containers that are using fan networking and I believe Juju should return the appropriate interface to use across this relation.