-
Notifications
You must be signed in to change notification settings - Fork 55
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
feat: KMP periodic retrieval with k8s requeue #1625
base: dev
Are you sure you want to change the base?
Conversation
pkg/controllers/clusterresource/keymanagementprovider_controller.go
Outdated
Show resolved
Hide resolved
dae0f30
to
234e835
Compare
Would like to understand the scope of this PR. If docs and e2e tests will be included in this PR |
Please complete test coverage section once PR is ready for Review. Here are some suggestion, let us know if you have any questions, thanks!
|
My thinking was this PR would include the changes to the KMP resource that enabled the refresh possible for clustered and namedspaced resources of the KMP. I was thinking the e2e tests would be a separate PR but, I don't have a strong opinion. So, if it's preferred to have them in this PR, that's fine with me also. |
I think e2e can be a separate PR if this PR is covered by manual testing. @duffney , do you think this PR will be ready for review this week? |
ca14514
to
7f195ad
Compare
@susanshi the PR is ready for another around of review. :) I just pushed changes that add the refresh interface to namespaced resources. I'll work on manually testing these changes and documenting the steps. That'll give me a better idea of how to build the e2e test for the next PR. |
a237ec3
to
ef0ec99
Compare
discussed in PR review , for 1.3 default to empty string ( disable refresh) , in 1.4, once we support N version of cert , default to 1min. (Note the breaking scenario of disabled key/cert) |
@susanshi is the default to 1 min too short? The key/cert is not likely to be rotated in such a short period normally. |
ef0ec99
to
20f09ea
Compare
@susanshi, can you elaborate on what you're meaning by this test? Does this mean that the user defined and interval and then replaced it with a different value later on? |
// Note: for backwards compatibility in upgrade scenarios, Ratify will only log a warning statement. | ||
logger.Warn("Certificate Store already exists. Key management provider and certificate store should not be configured together. Please migrate to key management provider and delete certificate store.") | ||
// check if kr.client is nil | ||
if kr.Client == nil { |
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.
curious if we can check r.Client == nil
before line 44?
@@ -31,6 +31,9 @@ type KeyManagementProviderSpec struct { | |||
// Name of the key management provider | |||
Type string `json:"type,omitempty"` | |||
|
|||
// +kubebuilder:default="" | |||
Interval string `json:"interval,omitempty"` |
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.
wonder if we should call it interval or refreshInterval?
"context" | ||
) | ||
|
||
type Refresher interface { |
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.
nit: could you add comments on exported interface and API functions?
} | ||
|
||
return ctrl.Result{}, client.IgnoreNotFound(err) | ||
kr := refresh.KubeRefresher{ |
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.
Since we already defined Refresher
interface, I feel we can have a factory for it and create an Refresher object instead of a concrete implementation struct.
Hi Yi, the scenario in mind how long does customer have to wait for the refresh. In scenarios like changes in permission role assignment, customer might want to wait short amount of time to validate that the cert retrieval succeeded. KV providers have thousands of transaction limit per 10 sec, there is no concern from the request throttling side. |
@@ -50,6 +50,9 @@ spec: | |||
spec: | |||
description: KeyManagementProviderSpec defines the desired state of KeyManagementProvider | |||
properties: | |||
interval: |
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.
Suggestion to add some samples of refresh interval configured AKV in the samples dir thanks! , https://github.com/ratify-project/ratify/tree/dev/config/samples
subresources: | ||
status: {} | ||
interval: | ||
default: "" |
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.
please add description for the interval property. Suggestion to also mention this is only application to "refreshable" providers
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.
examples of the allowed values would also be helpful .thanks!
thanks for confirming @joshuaphelpsms. Yes that is correct, exactly , "the user defined and interval and then replaced it with a different value later on" |
Description
Implements a periodic refresh for KMP resources deployed to Kubernetes by using the controller's re-queue functionality.
What this PR does / why we need it:
Adds two new properties to the KMP CRD spec
Interval
andRefreshable
. Interval determines the amount of time in-between refreshes. Refreshable determines if the resources is eligible for refresh.Logic from the controller's reconcile method has been abstracted into a new
refresh
interface. TODO: more detailsWhich 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 #1131
Type of change
Please delete options that are not relevant.
main
branch)How Has This Been Tested?
Unit Tests:
Manual Tests:
Behavior:
E2E
Checklist:
Post Merge Requirements
Helm Chart Change