-
Notifications
You must be signed in to change notification settings - Fork 40.2k
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
fix rbd info when return warning information #75588
Conversation
Hi @smileusd. Thanks for your PR. I'm waiting for a kubernetes 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. |
Has anyone to review this? @neolit123 @msau42 @cofyc |
/ok-to-test |
pkg/volume/rbd/rbd_util.go
Outdated
if startJson > endJson { | ||
return 0, fmt.Errorf("can't find json result") | ||
} | ||
if err := json.Unmarshal([]byte(string(output)[startJson: endJson+1]), &info); err != 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.
This way to filter out warning infos is too hacky. And mount.Exec
does not provide a method to filter out stderr stream too.
How about using -c /dev/null
to override ceph configuration? rbd
command will use this empty configuration file, no warnings will be emitted.
Actually, for kubelet rbd plugin, all required information to access ceph cluster are provided from command line arguments.
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.
Sorry to late reply. Actually it is to abort the configurations file all the rbd command if follow you suggested. Is it necessary?
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.
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 don't understand Ceph enough to judge if it's a common thing to configure its client via config in /etc/ on every node. Are all options really configurable via Kubernetes PV? If we remove parsing of /etc/, how likely is some cluster going to break?
There should be at least some a warning in release notes + deprecation period.
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.
It is not a common thing to configure its client via config in /etc
on every node. It's hard to maintain (need to copy configurations to every new node), and easy to make mistakes. All required options are configurable via Kubernetes PV and client arguments will override configurations in /etc/ceph
.
In fixing this bug, I don't it is necessary to warn users that we don't support reading configurations from /etc/ceph
because we have all required arguments in the command line:
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.
@cofyc @jsafrane Thank you and I make sense. If required arguments in the command line in code at beginning, it will not break exist cluster. And if we make sure all the arguments of the command will override the options of config file, it is safety to do following @cofyc says. But I will also make annotations to attention user not necessary to config /etc/ceph
in code.
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.
@cofyc I just came across this issue and I did a quick test in my environment, your suggestion to use -c /dev/null
will still output the following line to stderr:
2019-06-14 11:23:20.741527 7f1d737e60c0 -1 auth: unable to find a keyring on /etc/ceph/ceph.client.kube-admin.keyring,/etc/ceph/ceph.keyring,/etc/ceph/keyring,/etc/ceph/keyring.bin,: (2) No such file or directory
If you go that way you should also include -k /dev/null -K /dev/null
to point the keyrings to the empty file, this way only the rbd info will be outputted.
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.
touch a empty /etc/ceph/ceph.conf
and /etc/ceph/keyring
files should be work for take ceph client warning message away.
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.
@Symbianx You are right, but -K will cover the secret, i will change with -k /dev/null to cover it.
/lgtm I think this makes sense. We don't need to search keyring file because we provided the user and secret via |
@smileusd, can you please add release note to the first comment of this PR, so Ceph users are aware of this change? |
@smileusd: The label(s) In response to this:
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. |
@jsafrane updated. |
@smileusd: The label(s) In response to this:
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. |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jsafrane, smileusd 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 |
/retest Review the full test history for this PR. Silence the bot with an |
1 similar comment
/retest Review the full test history for this PR. Silence the bot with an |
What type of PR is this?
/kind bug
What this PR does / why we need it:
fix #75581
This pr clean rbd info command output of warning information. If not fix this, provider will parse the output error.
Special notes for your reviewer:
/sig storage
Does this PR introduce a user-facing change?: