-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
VAULT-29784: Skip connection verification on DB config read #28139
Conversation
CI Results: |
Build Results: |
@@ -392,6 +393,7 @@ func (b *databaseBackend) connectionReadHandler() framework.OperationFunc { | |||
} | |||
|
|||
resp.Data = structs.New(config).Map() | |||
delete(resp.Data, "verify_connection") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like something we could keep in the response.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was on the fence on this as well. I agree we can probably keep it so I'll remove that line!
Description
This PR solves a potential delay in reading existing DB connection configurations. When adding a computed
running_plugin_version
field to the response when reading a database configuration, we introduced the possibility of adding additional latency to this read request while attempting to verify the connection regardless of whether or notverify_connection
was set to false in the config. In the event that there was additional latency introduced, this had the potential of causing Terraform runs, or any other workflow that depended upon reading numerous DB connections, to take longer than expected. In the Terraform case this could lead to timeouts causing failures. This PR forces the skipping of the connection verification on DB configuration read. A side effect of this implementation is that we also respect theverify_connection
parameter further in the DB connection process during initialization which will result in slightly different error messaging in the event of a failed connection during a DB operation where the connection is not set to verify. If the configuration is set to skip verification, the connection is attempted and the error bubbles up, but will no longer be wrapped in aerror verifying connection
error message. This is not only clearer, but more in-line with what is expected based on configuration.TODO only if you're a HashiCorp employee
to N, N-1, and N-2, using the
backport/ent/x.x.x+ent
labels. If this PR is in the CE repo, you should only backport to N, using thebackport/x.x.x
label, not the enterprise labels.of a public function, even if that change is in a CE file, double check that
applying the patch for this PR to the ENT repo and running tests doesn't
break any tests. Sometimes ENT only tests rely on public functions in CE
files.
in the PR description, commit message, or branch name.
description. Also, make sure the changelog is in this PR, not in your ENT PR.