Bug 1874242: Revert "Bug 1857387: Do not reset the election-timer value"

[trozet]

Reverts #748

This PR stops election leader timers from being set to the default value of 5 seconds, because 5 is never less than 1.

[openshift-ci-robot]

@trozet: This pull request references Bugzilla bug 1857387, which is invalid:

• expected the bug to be in one of the following states: NEW, ASSIGNED, ON_DEV, POST, POST, but it is ON_QA instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

Revert "Bug 1857387: Do not reset the election-timer value"

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci-robot]

@trozet: This pull request references Bugzilla bug 1874242, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target release (4.6.0) matches configured target release for branch (4.6.0)
• bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

Bug 1874242: Revert "Bug 1857387: Do not reset the election-timer value"

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dcbw]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dcbw, trozet

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [dcbw]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[trozet]

@vishnoianil FYI

We shouldn't be allowing users to change settings underneath us and try to guess what their intention was. If they need to change the setting it should be done via CNO.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[dcbw]

@trozet @vishnoianil and rather than some knob in the CNO, if the value depends on cluster size, the CNO is fully capable of picking a number based on # nodes / # pods / whatever and deploying it to the cluster automatically, IMO

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[dcbw]

/override ci/prow/e2e-vsphere
/override ci/prow/e2e-azure
/override ci/prow/e2e-gcp-ovn
/override ci/prow/e2e-ovn-step-registry
/override ci/prow/e2e-openstack
/override ci/prow/e2e-ovn-hybrid-step-registry

[openshift-ci-robot]

@dcbw: Overrode contexts on behalf of dcbw: ci/prow/e2e-azure, ci/prow/e2e-gcp-ovn, ci/prow/e2e-openstack, ci/prow/e2e-ovn-hybrid-step-registry, ci/prow/e2e-ovn-step-registry, ci/prow/e2e-vsphere

In response to this:

/override ci/prow/e2e-vsphere
/override ci/prow/e2e-azure
/override ci/prow/e2e-gcp-ovn
/override ci/prow/e2e-ovn-step-registry
/override ci/prow/e2e-openstack
/override ci/prow/e2e-ovn-hybrid-step-registry

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci-robot]

@trozet: All pull requests linked via external trackers have merged:

• openshift/cluster-network-operator#769

Bugzilla bug 1874242 has been moved to the MODIFIED state.

In response to this:

Bug 1874242: Revert "Bug 1857387: Do not reset the election-timer value"

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[vishnoianil]

@vishnoianil FYI

We shouldn't be allowing users to change settings underneath us and try to guess what their intention was. If they need to change the setting it should be done via CNO.

@trozet
CNO is not guessing here, it's just trying to not override if user manually configure the value. OVN itself is a one big subsystem underneath and exposes it's own API that user can use to change config. If we really want user to not change the values i think we should not allow permission to user to use those utility tools. Unfortunately, CNO is not very flexible when it comes to changing the values, for that you need to stop CVO & it will restart all the pods, which you don't want to do in production environment.

The option @dcbw mentioned below seems a bit better option, but until and unless cluster deny the new node joining if it passes that #node, you are always at the risk that user can add more nodes. If user add more nodes and raft start partitioning more frequently, what is our options ? Do we ask user to disable CVO and change the value through CNO?

[vishnoianil]

@trozet @vishnoianil and rather than some knob in the CNO, if the value depends on cluster size, the CNO is fully capable of picking a number based on # nodes / # pods / whatever and deploying it to the cluster automatically, IMO

@dcbw Please see my above comment.

[vishnoianil]

@vishnoianil FYI
We shouldn't be allowing users to change settings underneath us and try to guess what their intention was. If they need to change the setting it should be done via CNO.

CNO is not guessing here, it's just trying to not override if user manually configure the value. OVN itself is a one big subsystem underneath and exposes it's own API that user can use to change config. If we really want user to not change the values i think we should not allow permission to user to use those utility tools. Unfortunately, CNO is not very flexible when it comes to changing the values, for that you need to stop CVO & it will restart all the pods, which you don't want to do in production environment.

The option @dcbw mentioned below seems a bit better option, but until and unless cluster deny the new node joining if it passes that #node, you are always at the risk that user can add more nodes. If user add more nodes and raft start partitioning more frequently, what is our options ? Do we ask user to disable CVO and change the value through CNO?

@trozet thanks for reverting the patch, when i tested the patch, i was testing it after setting the higher value manually and restarting it. Forgot the default 1 second case. Dumb mistake.