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

[Mirek]

If data binding exists as a "space" in MAAS but it's not available on a nova-compute unit, join ovn hook failed with network-get data exit code 1. It's a misconfiguration from my end but currently, there is no overlay/data binding on nova-compute unit and when I deployed nova-compute on a host which hasn't got overlay subnet configured, ovn-chassis configured to use overlay as "data" binding will fail on network-get data command, which make sense as a network isn't available but as ovn-chassis is a subordinate charm of nova-compute should nova-compute have an option to define overlay space as well, it's an easy to miss config issue which could easily be avoided if my machine won't deploy nova-compute if overlay space binding is defined on Juju but not present on MAAS machine used for deployment.

[Drew Freiberger (afreiberger)]

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.

[John A Meinel (jameinel)]

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.

[Billy Olsen (billy-olsen)]

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.

[Billy Olsen (billy-olsen)]

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

[Canonical Juju QA Bot (juju-qa-bot)]

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.

[Peter Matulis (petermatulis)]

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