-
Notifications
You must be signed in to change notification settings - Fork 332
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
issue-384, A single "default" storage class secret is added #393
Conversation
Welcome @taaraora! |
Hi @taaraora. Thanks for your PR. I'm waiting for a kubernetes-csi member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
1a38101
to
cb84e09
Compare
/ok-to-test |
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.
Can you add some unit tests that use the new default secret?
Another thing to keep in mind, allowable secret templates are different for provisioning compared to the other operations. We should make sure we can maintain that behavior for the default secret.
/assign @misterikkit |
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.
Thanks for the enhancement! Looks like it will save us some API bloat in the future.
Functional change LGTM. Please add some test coverage.
prefixedDefaultSecretNameKey: "csiBar", | ||
prefixedDefaultSecretNamespaceKey: "csiBar", |
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.
Does this change cover the new logic, or just fix an existing test? I think we should add a case that gets the default value.
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 was just fix of existing test. I've added a few new tests for default secret.
|
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.
Thanks for adding tests. Do you mind squashing the commits?
pkg/controller/controller_test.go
Outdated
// Minimal PVC required for tests to function | ||
func createFakePVC(requestBytes int64) *v1.PersistentVolumeClaim { | ||
// createFakeNamedPVC creates PVC for tests, should be extended with new args when needed | ||
func createFakeNamedPVC(requestBytes int64, name string, userAnnotations ...struct{ Key, Value string }) *v1.PersistentVolumeClaim { |
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.
Any reason userAnnotations
is a slice of struct rather than a map[string]string
? The call site that uses this new arg is overly verbose.
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.
Yes, the current signature makes userAnnotations
argument optional. If we change it to map it will require to add an empty map to each place where this function is invoked now.
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.
Seems like not too many call sites? Alternatively, since you only use userAnnotations
in one place, you could make it a different helper function with a longer, more specific name.
The most comprehensive solution would be to adopt the standard "function options" pattern, but that may be overkill.
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.
Hm, I agree with you, a different helper function is the better way to handle this.
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.
Fixed, it is map[string]string
now.
pkg/controller/controller_test.go
Outdated
@@ -477,13 +477,18 @@ func provisionFromPVCCapabilities() (rpc.PluginCapabilitySet, rpc.ControllerCapa | |||
} | |||
} | |||
|
|||
// Minimal PVC required for tests to function | |||
func createFakePVC(requestBytes int64) *v1.PersistentVolumeClaim { | |||
// createFakeNamedPVC creates PVC for tests, should be extended with new args when needed |
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.
should be extended with new args when needed
I don't understand what you mean, since this could apply to any helper function. Could you elaborate?
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.
Thank you, that makes sense, I can just delete it.
pkg/controller/controller_test.go
Outdated
@@ -1229,6 +1382,31 @@ func TestProvision(t *testing.T) { | |||
expectErr: true, | |||
expectState: controller.ProvisioningNoChange, | |||
}, | |||
"fail to get secret reference for default secret parameter template with annotation": { |
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.
Is the failure caused by mismatch between secret-from-annotation
and default-secret-from-annotation
? If so, could you make the names more distinct? Thanks.
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.
As @msau42 pointed out the default secrets can support only that set of template variables which is common for all calls. In this test, I showed that the annotation variable is not supported by the default secret. Should I rename this test?
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 think after that explanation, the test name makes sense. I just find the existing logic with secret references and template evaluation to be confusing. 😢
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.
Now that I re-read the test, maybe we can update the name to mention invalid/illegal template variable.
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.
Fixed.
/retest |
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
nice job refactoring the tests.
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: msau42, taaraora The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #384
Special notes for your reviewer:
Does this PR introduce a user-facing change?: