fix: disable APF feature flag to prevent readyz-blocking informers#30
fix: disable APF feature flag to prevent readyz-blocking informers#30scotwells wants to merge 3 commits into
Conversation
|
Closing — this fix is not needed. The APF informers only failed because |
|
Re-opening. Neither the quota nor the activity service has a NetworkPolicy, so they can't confirm the |
1799a10 to
f6f7489
Compare
Reverted 1 infected file(s) to main state and removed 0 attacker-created file(s). Restored .env / .env.local in .gitignore. Note: any legitimate changes that branch made to the reverted files were lost in the revert; re-apply them manually after review.
Problem
The IPAM apiserver pods are stuck
0/1 Readyin staging. The readiness probe returns HTTP 500 indefinitely:Why the previous fix (#29) didn't work
PR #29 moved
genericConfig.FlowControl = nilto afterApplyTo, reasoning thatApplyTore-initializes the field. That was correct but incomplete.The real problem:
FeatureOptions.ApplyTocallsutilflowcontrol.New(informers, ...), which registersFlowSchemaandPriorityLevelConfigurationevent handlers directly on theSharedInformerFactory. SettingFlowControl = nilafterward removes the controller reference but does nothing to the factory — those informers remain registered and appear in theinformer-syncreadyz check, where they block readyz because the IPAM apiserver has noflowcontrol.apiserver.k8s.ioaccess.Fix
Set
EnablePriorityAndFairness = falseonRecommendedOptions.FeaturesinNewIPAMServerOptions(), beforeApplyTois ever called. This causesFeatureOptions.ApplyToto skip theutilflowcontrol.New()call entirely — the informers are never registered, and readyz is unblocked.The now-redundant
genericConfig.FlowControl = nilis removed.🤖 Generated with Claude Code