IPPool controller enters infinite reconciliation loop due to unconditional timestamp updates #1071
Description
What steps did you take and what happened:
Deploy an IPPool resource and observe the controller behavior. The IPPool controller enters an infinite reconciliation loop where it continuously patches the IPPool object with updated LastUpdated timestamps, even when no actual IP address allocations or claims require processing.
Steps to reproduce:
- Create an IPPool resource with any valid configuration
- Monitor the controller logs - observe repeated "Fetching IPAddress objects" messages
- Monitor the IPPool resource - observe
status.lastUpdatedfield being updated continuously - Check API server metrics - observe high PATCH request volume for IPPool objects
What did you expect to happen:
The IPPool controller should only update the status.lastUpdated field when actual changes occur to IP allocations, not on every reconcile cycle. The controller should reach a steady state with minimal API calls when no address claims need processing.
Anything else you would like to add:
Root Cause Analysis:
The issue is in ippool_manager.go where updateStatusTimestamp() is called unconditionally in multiple methods:
- Line 258:
m3UpdateAddresses()always callsupdateStatusTimestamp() - Line 296:
capiUpdateAddresses()always callsupdateStatusTimestamp() - Line 886:
deleteAddress()always callsupdateStatusTimestamp() - Line 962:
capiDeleteAddress()always callsupdateStatusTimestamp()
Technical Details:
Each reconcile cycle calls both m3UpdateAddresses() and capiUpdateAddresses(), and both methods call getIndexes() which performs expensive LIST operations. Even when no claims exist or require processing, the methods still update timestamps, triggering new reconcile cycles.
The getIndexes() method already correctly handles timestamp updates (line 195) only when allocations actually change. The additional unconditional calls can be removed.
/kind bug