OpenStack Octavia Charm

octavia bind_ip not always set by charm

Bug #1843636 reported by Edward Hope-Morley
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Octavia Charm
Triaged
High
Unassigned

Bug Description

Upon reboot and/or scale-out I am noticing that bind_ip does not always get set:

$ juju run -a octavia -- grep bind_ip /etc/octavia/octavia.conf
- ReturnCode: 1
  Stdout: ""
  UnitId: octavia/0
- Stdout: |
    bind_ip = fc00:c76d:2df3:6ecd:f816:3eff:fe5b:eac5
  UnitId: octavia/2
- Stdout: |
    #bind_ip = 127.0.0.1
  UnitId: octavia/3
- Stdout: |
    bind_ip = fc00:c76d:2df3:6ecd:f816:3eff:fed3:6f14
  UnitId: octavia/1

This results in some octavia units being unusable.

Edward Hope-Morley (hopem)
Changed in charm-octavia:
milestone: none → 19.10
Revision history for this message
Frode Nordahl (fnordahl) wrote :

At time of config render the charm currently attempts to get this information from the runtime configuration of the ``o-hm0`` interface.

As you have found and described this is racy as there is no guarantee that the interface has configured itself at that point in time.

Other options could be to load state from Neutron, or store a extra state in the charm with the address.

Changed in charm-octavia:
status: New → Triaged
importance: Undecided → High
Revision history for this message
Edward Hope-Morley (hopem) wrote :

@fnordahl yes that sounds about right. I had another concern that i forgot to add to my original post which is that for me the real problem was that the octavia api is up+running and able to service requests despite this not being set yet and what happens is that it tries to create an amphora vm and cannot reach it. I think that we need to do two things (a) cache the port mac so that on reboot it can be set automatically (and maybe dbl check that of the port currently attached just in case) and (b) ensure that the api and worker does not run until bind_ip is configured correctly.

Revision history for this message
Edward Hope-Morley (hopem) wrote :

extra bit of info is that in my case, the reason why some octavia units were not getting an address on o-hm0 was that some units were not receiving their v6 RA due to https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1843557

David Ames (thedac)
Changed in charm-octavia:
milestone: 19.10 → 20.01
Alex Kavanagh (ajkavanagh)
tags: added: cold-start scaleout
James Page (james-page)
Changed in charm-octavia:
milestone: 20.01 → 20.05
David Ames (thedac)
Changed in charm-octavia:
milestone: 20.05 → 20.08
James Page (james-page)
Changed in charm-octavia:
milestone: 20.08 → none
Revision history for this message
Edward Hope-Morley (hopem) wrote :

I have a feeling that https://bugs.launchpad.net/charm-octavia/+bug/1902765 is the real root cause if this problem.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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