Closed mgencur closed 4 years ago
While this is unfortunate, this is a major change in mode of operation of the system and I guess asking for a restart is reasonable (I think directly switching to HA mode would be a bit hard to implement). Also related to Matt's latest doc. /cc @mattmoor @pmorie
TBH, my preference would be to get enough mileage through the leader election code that we can just enable it by default and remove that moving part.
We could start with a PR that enables it by default, uses just one pod for every controller (same as now) and runs all test suites in this mode except for HA tests where it would be enough to add one more pod which would automatically run in leader-election mode.
Any objections on enabling this by default for all components now?
Linking the other issue that is related: https://github.com/knative/pkg/issues/1319 It will affect implementation significantly.
The first impl is here: https://github.com/knative/serving/pull/8205 . We should consider knative/pkg#1319 before merging it.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen
. Mark the issue as
fresh by adding the comment /remove-lifecycle stale
.
When leader election is enabled at runtime in the
config-leader-election
ConfigMap the existing pods do not apply these settings. They continue running in the normal mode and later when more pods are started for a controller and the new leader is elected this original controller keeps reconciling knative resources, together with any new leader This leads to race conditions. The user has to manually restart the pods after applying those settings.What version of Knative?
Expected Behavior
The leader election mode is reliably enabled after changing the config-leader-election ConfigMap.
Actual Behavior
The existing pod keeps running in non-leader-elected mode and keeps reconciling services together with any new leader controller.
Steps to Reproduce the Problem