Skip to content

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

Merged
deepthi merged 1 commit intovitessio:masterfrom
tinyspeck:update-timeout
Aug 26, 2020
Merged

Updates enforcement policy to match the one from the client#6629
deepthi merged 1 commit intovitessio:masterfrom
tinyspeck:update-timeout

Conversation

@rafael
Copy link
Copy Markdown
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
// 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
Copy Markdown
Collaborator

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
Copy Markdown
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
Copy Markdown
Collaborator

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