[OVN] neutron agent not cleaned up at departure causes new units to fail
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Neutron API Charm |
New
|
Undecided
|
Unassigned | ||
charm-ovn-central |
New
|
Undecided
|
Unassigned | ||
charm-ovn-chassis |
New
|
Undecided
|
Unassigned |
Bug Description
$ openstack network agent list shows:
| juju-d34d64-
In which the agent is marked as gone.
Indeed, that is corresponding to an octavia unit (25/lxd/6) which has been previously removed.
I can also see it on Chassis table: https:/
As well as other ovn-chassis units that have been previously removed.
I can also see it in Encap table:
_uuid : 157c9a73-
chassis_name : juju-d34d64-
ip : "IP" <<<<<--
options : {csum="true"}
type : geneve
My issue is that, redeploying a new unit for octavia (in this case, 25/lxd/10) does not eventually work, since the ovn-chassis charm accompanying it cannot register itself.
In the /var/log/
2021-06-
According to:
https:/
That happens because "IP" is being reused, and given the automation (in our case, the charms) did not clean the previous entries; then this new ovn-chassis unit cannot register itself.
A comment on the bug above uggests that ovn-sbctl should be used to clean those entries.
The equivalent neutron agent should also be cleaned up.