principal application doesn't consider its subordinate bindings
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
Deployed neutron-openvswitch as the subordinate of octavia with binding "data: overlay-space". Install hook failed because no network config found for binding "data". there's no overlay-space called out by the principal octavia bindings. It should consider subordinate bindings when defining the spaces to add to a new machine. The workaround is to run "juju set-constraints octavia spaces=
$ juju run -u neutron-
ERROR no network config found for binding "data"
------
neutron-
charm: cs:neutron-
options:
bridge-
dns-servers: x.x.x.x
firewall-
prevent-
worker-
bindings:
"": oam-space
amqp: internal-space
data: overlay-space
juju-info: oam-space
neutron-
neutron-
neutron-
So there is a race condition wrt having this work for subordinates (today).
A bundle that says:
applications:
primary:...
subordinate:...
relations:
- [primary, subordinate]
Actually is equivalent to:
juju deploy primary
juju deploy subordinate
juju relate primary subordinate
And the issue is that once you've done "juju deploy primary", Juju will start trying to provision a machine for the units of that application. The subordinate likely doesn't exist in the model yet.
Once you do finish deploying the subordinate and then relating it, then we could know about it, but with the current implementation of bundles means that it would always be 'racy'. It would work well for 'add-unit' but deploying the bundle would at best be inconsistent.
We are looking at moving bundles to being unpacked on the server instead of being driven by the client, which would give us more ability to apply the entire changes to the model rather than slowly adding the changes over time.
In the mean time, the workaround is to use spaces as part of the constraints along with bindings.