-
Notifications
You must be signed in to change notification settings - Fork 764
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
docs: adds documentation about provider response caching #2927
Conversation
website/docs/externaldata.md
Outdated
@@ -146,6 +146,9 @@ If there is a system error, the provider should return the system error message | |||
|
|||
Example provider implementation: https://github.com/open-policy-agent/gatekeeper/blob/master/test/externaldata/dummy-provider/provider.go | |||
|
|||
#### Caching | |||
Gatekeeper now supports caching of responses from external data providers. It caches the response based on the `Key` and `Value` received as part of the [`ProviderResponse`](#providerresponse). By default, the cache is invalidated after 3 minutes, which is the default Time-to-Live (TTL). You can configure the TTL using the --external-data-provider-response-cache-ttl flag. |
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.
Gatekeeper now supports caching of responses from external data providers. It caches the response based on the `Key` and `Value` received as part of the [`ProviderResponse`](#providerresponse). By default, the cache is invalidated after 3 minutes, which is the default Time-to-Live (TTL). You can configure the TTL using the --external-data-provider-response-cache-ttl flag. | |
Starting with v3.13+, Gatekeeper supports caching of responses from external data providers. It caches the response based on the `Key` and `Value` received as part of the [`ProviderResponse`](#providerresponse). By default, the cache is invalidated after 3 minutes, which is the default Time-to-Live (TTL). You can configure the TTL using the `--external-data-provider-response-cache-ttl` flag. |
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.
Do we want to give the version when a feature arrives? Is that implicit in the versioning of docs?
Definitely prefer listing a specific version to "now supports"
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.
+1 on adding something like, similar to how we have been communicating feature status and GK versions
Feature State
: Gatekeeper version v3.11+ (beta)
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.
SGTM
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 added Starting with v3.13+, Gatekeeper supports...
per @sozercan suggestion. Does that work?
website/docs/externaldata.md
Outdated
@@ -146,6 +146,9 @@ If there is a system error, the provider should return the system error message | |||
|
|||
Example provider implementation: https://github.com/open-policy-agent/gatekeeper/blob/master/test/externaldata/dummy-provider/provider.go | |||
|
|||
#### Caching | |||
Gatekeeper now supports caching of responses from external data providers. It caches the response based on the `Key` and `Value` received as part of the [`ProviderResponse`](#providerresponse). By default, the cache is invalidated after 3 minutes, which is the default Time-to-Live (TTL). You can configure the TTL using the --external-data-provider-response-cache-ttl flag. |
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.
Do we want to give the version when a feature arrives? Is that implicit in the versioning of docs?
Definitely prefer listing a specific version to "now supports"
b189d28
to
8103cd9
Compare
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.
LGTM
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.
LGTM
pending version docs update
8103cd9
to
cde6f82
Compare
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.
LGTM
Signed-off-by: Nilekh Chaudhari <[email protected]>
cde6f82
to
7b6f44d
Compare
…-agent#2927) Signed-off-by: Nilekh Chaudhari <[email protected]> Signed-off-by: DC ground <[email protected]>
…-agent#2927) Signed-off-by: Nilekh Chaudhari <[email protected]>
…-agent#2927) Signed-off-by: Nilekh Chaudhari <[email protected]>
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, using
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when the PR gets merged):Fixes #
Special notes for your reviewer: