Closed r4f4 closed 2 weeks ago
/triage accepted
Hey @nrb @damdo there is a hypothetical leak situation we (@r4f4 and me) caught while reviewing https://github.com/kubernetes-sigs/cluster-api-provider-aws/pull/5017 , I will describe here to document:
It is unrelated with the PR #5017 but may be related with the issue with new target groups and listeners which are now reconciled in their own loop ( https://github.com/kubernetes-sigs/cluster-api-provider-aws/pull/5004 ).
I was thinking how to reproduce leak with the server-side failure on API call CreateListener
, but I can't see much options with gomock, and the AWS FIS does not support actions to ELB service API.
LMK if it is related here or want to open a new issue. Thanks
Hey @mtulio if we don't plan to fix it via #5017 let's create a new issue and track that there. Thanks!
/kind bug
What steps did you take and what happened:
With https://github.com/kubernetes-sigs/cluster-api-provider-aws/pull/5004, target groups and listeners are now reconciled in their own loop. The problem now is that every time the reconcile loop runs, this check is never true because the target desiredSpec contains newly-generated values for the TG names in every iteration.
There is a chance the e2e tests do not create v2 ELBs, so this code path was never exercised.
What did you expect to happen:
The reconcile loop can identify when it's done and it doesn't try to create duplicate target groups and listeners.
Anything else you would like to add:
Here is an excerpt of the logs from a failed run in openshift:
Environment:
kubectl version
):/etc/os-release
):