principal application doesn't consider its subordinate bindings

Bug #1934283 reported by Linda Guo
8
This bug affects 1 person
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=overlay-space" , then redeploy the principal application octavia

$ juju run -u neutron-openvswitch-octavia/2 'network-get --primary-address data'
ERROR no network config found for binding "data"

------
  neutron-openvswitch-octavia:
    charm: cs:neutron-openvswitch-282
    options:
      bridge-mappings: xxxxabric:br-data
      dns-servers: x.x.x.x
      firewall-driver: openvswitch
      prevent-arp-spoofing: true
      worker-multiplier: 0.25
    bindings:
      "": oam-space
      amqp: internal-space
      data: overlay-space
      juju-info: oam-space
      neutron-control: oam-space
      neutron-plugin: oam-space
      neutron-plugin-api: oam-space

Linda Guo (lihuiguo)
description: updated
Linda Guo (lihuiguo)
description: updated
Revision history for this message
John A Meinel (jameinel) wrote :

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.

Changed in juju:
importance: Undecided → Wishlist
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.