If data binding exists as a space but it's not avaiable on nova-compute unit, join ovn hook failed with network-get data exit code 1

I ran into this today, and it seems this is potentially a juju bug.

The principal charm, octavia, in my case, doesn't have a binding that maps to the space used by the ovn-chassis-octavia data binding.

For instance, octavia using all "oam-space" bindings, but ovn-chassis-octaiva using binding data=overlay-space, juju didn't configure the new octavia lxd (maas provider) with an overlay-space interface.

I would suggest that if juju knows about subordinates related to a new principal unit at deployment time (i.e, the subordinate relation is already defined in the model or bundle being deployed) it should also configure interfaces for subordinate charm space bindings.

Workaround in my case was to add a constraint to octavia: 'juju set-constraints octavia spaces=overlay-space' and then re-deploy octavia units.

My environment is running juju 2.8.7 model/agents.

The fact that we allow machines to also support --constraints spaces=X,Y,Z was specifically to handle the case of knowing that there is additional spaces that you need access to (for whatever reason, whether it is subordinates or future applications).

That said, when evaluating a bundle we could look at all applications that are assigned for a machine.

I think this is something we should be a bit better about in the OpenStack Charm documentation, namely the space considerations and how spaces should be laid out and various considerations. It may still lead to user configurations here and there, but we should provide more concise documentation on spaces and considerations for deployment.

The charm readme should also probably call this out when discussing the spaces.

This Medium-priority bug has not been updated in 60 days, so we're marking it Low importance. If you believe this is incorrect, please update the importance.

The Charm Guide now includes detailed information on using network spaces in a Charmed OpenStack context. It does explicitly mention that spaces for subordinate charms must be a subset of those of the principal [0] as well as state that an assigned binding does not guarantee network connectivity. Consequently, I'm going to remove the bug task for the Charm Guide.

[0]: https://docs.openstack.org/charm-guide/latest/concepts/spaces.html#subordinate-applications