Description of problem:
After deleting a BFDProfile object the corresponding running-conf from the MetalLB speakers does not get deleted
Version-Release number of selected component (if applicable):
OCP Version: 4.10.0-fc.2
Kubernetes Version: v1.23.0+60f5a1c
MetalLB Version: 4.10.0-202201210948
Steps to Reproduce:
1. Create a bfdprofile object
2. Check that the corresponding bfd profile configuration is loaded into the MetalLB speakers
3. Delete the bfdprofile object:
$ oc delete bfdprofile bfdprofilefull
bfdprofile.metallb.io "bfdprofilefull" deleted
The corresponding bfd profile is not deleted from the running-config of the speakers:
$ oc -n metallb-system rsh speaker-9pcl2
sh-4.4# sh running-config
The corresponding bfd profile gets deleted from the running-config of the speakers
BTW, at the moment of the BFDProfile deletion we did not have any BGPPeers using the BFDProfile:
$ oc get bgppeer -o yaml
- apiVersion: metallb.io/v1beta1
I can confirm this bug. My test environment is upstream main MetalLB.
1. create BGP peer and BFD profile in MetalLB's ConfigMap
2. verify BGP peer is using expected BFD Profile
3. delete BFD profile and unreferenced it from the BGP peer
4. verify that BFD profile is still defined in FRR and that the BGP peer still has BFD on (although not set to the deleted BFD profile)
If only the BFD profile was still configured in FRR, this bug would have a severity. However, the BGP peer still has BFD enabled (default BFD profile) so this can cause data-plane outages.
kind-control-plane# show running-config
router bgp 64512
bgp router-id 126.96.36.199
no bgp ebgp-requires-policy
no bgp default ipv4-unicast
no bgp network import-check
neighbor 10.0.0.1 remote-as 64512
neighbor 10.0.0.1 bfd <----------------------
(In reply to Carlos Goncalves from comment #2)
> If only the BFD profile was still configured in FRR, this bug would have a
> severity. However, the BGP peer still has BFD enabled (default BFD profile)
> so this can cause data-plane outages.
If only the BFD profile was still configured in FRR, this bug would have a *low* severity.
OpenShift has moved to Jira for its defect tracking! This bug can now be found in the OCPBUGS project in Jira.