octavia bind_ip not always set by charm

[Edward Hope-Morley]

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.

[Frode Nordahl (fnordahl)]

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.

[Edward Hope-Morley (hopem)]

@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.

[Edward Hope-Morley (hopem)]

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

[Edward Hope-Morley (hopem)]

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