-
Notifications
You must be signed in to change notification settings - Fork 69
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(helm): Make log verbosity configurable #397
Conversation
Sorry for the noise, I changed |
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.
@ianroberts , Thanks for raising the PR, have provided a few comments
Make log verbosity level configurable via chart values, rather than hard-coding --v values (several components are currently set at --v=5, the most verbose level, intended for trace-level logging). For backwards compatibility the defaults are set to match the previous hard-coded values everywhere, but this can now be overridden via csiController.{attacher|provisioner|resizer|snapshotController}.logLevel for the controller (or csiController.logLevel to set the default for all four), csiNode.driverRegistrar.logLevel for the CSI node and cvcOperator.logLevel for the CVC operator. Signed-off-by: Ian Roberts <[email protected]>
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
This is a modification to openebs-archive#161 to reverse the order of the overriding between csiController.logLevel and csiController.<container>.logLevel following discussions on openebs-archive/cstor-operators#397. Now csiController.logLevel sets a default at the pod level, and csiController.*.logLevel overrides that default for the relevant pod. Signed-off-by: Ian Roberts <[email protected]>
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
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
This is a modification to #161 to reverse the order of the overriding between csiController.logLevel and csiController.<container>.logLevel following discussions on openebs-archive/cstor-operators#397. Now csiController.logLevel sets a default at the pod level, and csiController.*.logLevel overrides that default for the relevant pod. Signed-off-by: Ian Roberts <[email protected]>
A number of components in the helm charts have hard-coded
--v=5
options which can produce overly-verbose logging. I recently submitted openebs-archive/jiva-operator#161 to fix this in the Jiva chart and was asked by @prateekpandey14 to port the same changes here for cStor.What this PR does?:
This PR makes various
--v
flags configurable via the values file/--set
. To maintain backwards compatibility the defaults invalues.yaml
remain at the previously hard-coded values but they can now be overridden viacsiController.logLevel
to change all the CSI controller containers to the same level in one go. If this value is not set then we fall back to per-container settings, all of which default to "5"csiController.attacher.logLevel
csiController.provisioner.logLevel
csiController.resizer.logLevel
csiController.snapshotController.logLevel
csiNode.logLevel
as above for the CSI node pod, though there is only one container-specific child value in this case:csiNode.driverRegistrar.logLevel
for the node pod driver registrarcvcOperator.logLevel
for the CVC operator (default level 2)Edit: following discussion this has now been changed so that the top-level per-pod settings provide the defaults in
values.yaml
, and the per-container settings can be supplied to override the default.Note I have only added options for those cases where there is already a
--v
option specified in the helm template. There may be other components that could accept--v
but where the chart does not currently pass one, but I don't use cStor myself (this PR is a port of changes I made to Jiva) and don't know the code so I've limited myself to the obviously non-breaking changes.Does this PR require any upgrade changes?:
No