-
Notifications
You must be signed in to change notification settings - Fork 544
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
Add tags to EFS resources. Update EFS Utils #309
Conversation
Hi @kbasv. Thanks for your PR. I'm waiting for a kubernetes-sigs 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. |
/ok-to-test |
26e60d0
to
08368aa
Compare
/retest |
3 similar comments
/retest |
/retest |
/retest |
60ab06a
to
e8d8e1d
Compare
@wongma7 dynamic provisioning e2e tests passes now |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kbasv, wongma7 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 |
@wongma7 @nckturner @kbasv |
@wongma7 @nckturner @kbasv |
coveralls is blocking. I guess it has a point this time, it wouldn't hurt for parsing functions to have some tests |
func parseTagsFromStr(tagStr string) map[string]string { | ||
defer func() { | ||
if r := recover(); r != nil { | ||
klog.Errorf("Failed to parse input tag string: %v", tagStr) |
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.
could you add a unit test for this, using at least the same example in the command help text.
Instead of panicking and recovering given invalid input, let's check the length of p
, this can be a test case as well.
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 can add a test here.
The panicking and recovering is when there is a typo in the input or the key value pair is not of the form key
:value
. For example: key-value key;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.
Checking for len would do the same thing but I guess it is a matter of style so it's fine. If len(p) is not 2, then the user must have made a typo like key-value
or key:value:key
etc.
I was thinking of just unit tests of parseTagsFromStr rather than "integration" test of all of CreateVolume but what you have added is fine
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.
Also WDYT about parsing at startup and fast failing instead of at createvolume time?
With current implementation, driver will startup and mount/unmount will still work but then all createvolumes will fail and the user will have to do debugging. Whereas if we fast fail they will presumably see the error message printed by the plugin
edit: never mind, I think it could be better to fail at createvolume time. Chasing logs of a crashlooping pod is not fun.
…n based on tags. * Add default tags and provide a command line option to provide more tags * Update permissions and efs-utils version
// mount access point | ||
command := exec.Command("/bin/sh", "-c", "mount", "-t", "efs", "-o", "tls,accesspoint="+accessPointId, FileSystemId, target) | ||
if err = command.Run(); err != nil { | ||
framework.ExpectNoError(err, "Failed to mount using access point") | ||
} |
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 this a test or setup step? If it's a test, shouldn't it be moved to a dedicated test method, rather than running in a BeforeSuite
? If it's a setup, why did we delete the access point afterwards?
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 is a setup step to bootstrap access points
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 expect users to do this? Do we need to document the need to bootstrap access points anywhere?
One last question: what do yo uthink about making tags a storageclass parameter instead of a command line flag? It is more flexible storageclass a could have its volumes tagged a certain way, b another way, and as a user I can more easijly audit both. e: we can always add this later. I think for now, making it a flag satisfies most usecases |
I like the idea of tags in the storage class parameters. We can eventually move it as a storage class parameter or we can do it now. I'm okay with either way |
/lgtm I am really wary of the e2e test changes, I think we need to document, but in interest of gathering data let's merge it and see if it helps with the test flakiness |
What is this PR about? / Why do we need it?
What testing is done?
Tested against my EKS cluster.
Ran
make test-e2e
on a fresh ec2 instance