-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
[WIP] Add resolution tips for volume mount errors via describe events #26366
Conversation
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
2 similar comments
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
@k8s-bot ok to test |
cc @kubernetes/sig-storage |
// AddMountErrorHint performs some basic analysis | ||
// on the current mount error returned and will | ||
// add a user hint or resolution tip for enhanced UXP | ||
func (kl *Kubelet) AddMountErrorHint(volpath string, volname string, inerr error) error{ |
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.
Not sure how I feel about this logic being centralized like this. It feels very much like a cross-cut, reading this logic for different volumes all in the same place. I don't think it's so bad to keep the logic at the call site it's relevant to.
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.
For the record I can totally understand the desire to keep this orthogonal from the volume plugins, but I think it's a fine start (and likely to work better in the Kubelet we have today) to keep the logic about possible error causes at the sites where they occur. I think that is the simplest way to start, and maybe a better pattern will become evident.
I like the concept here but I think this can just be additional information at the sites where these errors occur to start with. See #26366 (comment) |
based on comments above going to create a 2nd PR with implementation of logic in each plugin |
@screeley44 PR needs rebase |
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
2 similar comments
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
ok to test |
GCE e2e build/test passed for commit ff03d3f. |
This PR hasn't been active in 30 days. It will be closed in 59 days (Sep 22, 2016). You can add 'keep-open' label to prevent this from happening, or add a comment to keep it open another 90 days |
This is based on UXP and the idea of offering users some tips and hints on how to resolve common mounting errors. I've tossed around several implementation ideas for this but think this is the best approach since it centralizes the logic within the volumes.mountExternalVolumes.
Also there is some additional discussion for this in issue #23982
This also depends (at least for Glusterfs) that PR #24808 merges.
Anyway wanted to start some discussion on this. Below are some examples of the output a user would see based on this PR
if no match is found, then the normal error is returned without any additional hints...
Alternative Approaches could be:
@pmorie @erinboyd