Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates enforcement policy to match the one from the client #6629

Merged
merged 1 commit into from
Aug 26, 2020

Conversation

rafael
Copy link
Member

@rafael rafael commented Aug 26, 2020

Desc

  • Makes sure grpc_server_keepalive_enforcement_policy_min_time has a value that is compatible with grpc_keepalive_timeout. The value for the timeouts was recently change, but the enforcement policy was not updated.
  • Fixes this issue: set default grpc values #5922 (comment)

Tests

  • I did not test this PR. but I think CI should be sufficient.

Signed-off-by: Rafael Chacon <rafael@slack-corp.com>
@rafael rafael requested a review from sougou as a code owner August 26, 2020 18:09
@@ -86,7 +86,7 @@ var (

// EnforcementPolicy MinTime that sets the keepalive enforcement policy on the server.
// This is the minimum amount of time a client should wait before sending a keepalive ping.
GRPCKeepAliveEnforcementPolicyMinTime = flag.Duration("grpc_server_keepalive_enforcement_policy_min_time", 5*time.Minute, "gRPC server minimum keepalive time")
GRPCKeepAliveEnforcementPolicyMinTime = flag.Duration("grpc_server_keepalive_enforcement_policy_min_time", 10*time.Second, "gRPC server minimum keepalive time")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in addition to changing the default, we should also force the value if it violates the constraint we want to impose (that PolicyMinTime <= grpc_keepalive_timeout). Line 157.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I'm not sure if it should be up to us to do this kind of validations. I think that could be a slippery slope. Two things come to mind:

  • I think we already have many other settings that could create conflict if not configured correctly that we are not doing this.
  • Even if we add that validation we can't prevent that vtgates are configured incorrectly in respect to the flags that the user provides to the tablet (e.g you could configure the vtgates to be 10s and enforcement policy of 10s; then tablets to be 5s / 5s. The constraint you are proposing won't catch that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Valid points. We can merge this as-is.

@deepthi deepthi merged commit b90b9f5 into vitessio:master Aug 26, 2020
@askdba askdba added this to the v8.0 milestone Oct 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants