-
Notifications
You must be signed in to change notification settings - Fork 6
Implementing LeaderElectionRunnable for CostAccrual #95
Copy link
Copy link
Open
Labels
bugCategorizes issue or PR as related to a bug.Categorizes issue or PR as related to a bug.good first issueGood for newcomersGood for newcomershelp wantedExtra attention is neededExtra attention is neededneeds-priorityIndicates a PR lacks a label and requires one.Indicates a PR lacks a label and requires one.needs-triageIndicates an issue or PR lacks a label and requires one.Indicates an issue or PR lacks a label and requires one.
Description
Activity
Metadata
Metadata
Assignees
Labels
bugCategorizes issue or PR as related to a bug.Categorizes issue or PR as related to a bug.good first issueGood for newcomersGood for newcomershelp wantedExtra attention is neededExtra attention is neededneeds-priorityIndicates a PR lacks a label and requires one.Indicates a PR lacks a label and requires one.needs-triageIndicates an issue or PR lacks a label and requires one.Indicates an issue or PR lacks a label and requires one.
What happened:
A plain controller-runtime manager.Runnable does not opt into leader election; runnables that do not implement LeaderElectionRunnable are started on every replica. With HA replicas this loop therefore performs competing accrual writes and splits successful windows across process-local counters, exactly the state this comment intends to prevent. Make CostAccrual implement NeedLeaderElection() bool and return true.
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment: