Bug 1878040: Validations for LogLevel fields#736
Bug 1878040: Validations for LogLevel fields#736openshift-merge-robot merged 1 commit intoopenshift:masterfrom ricardomaraschini:loglevel-defaults
Conversation
|
@ricardomaraschini: This pull request references Bugzilla bug 1878040, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
DetailsIn 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. |
|
@ricardomaraschini: This pull request references Bugzilla bug 1878040, which is valid. 3 validation(s) were run on this bug
DetailsIn 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. |
1 similar comment
|
@ricardomaraschini: This pull request references Bugzilla bug 1878040, which is valid. 3 validation(s) were run on this bug
DetailsIn 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. |
|
/hold We have to wait until we have a cluster-config-operator controller in place that cleans up existing log level, compare openshift/cluster-config-operator#150 |
|
@sttts the PR that you mention is for 4.5, for openshift/cluster-config-operator#151 is for master and it is merged. Can we unhold this PR? |
|
openshift/cluster-config-operator#150 merged. /lgtm We now have to bump this into all these operators: |
|
/hold cancel |
|
/retest |
1 similar comment
|
/retest |
|
/retest |
1 similar comment
|
/retest |
|
/test unit |
|
/retest |
As it is stated on OperatorSpec.LogLevel documentation valid values for the type LogLevel are Normal, Debug, Trace and TraceAll. Adding pattern validation for the LogLevel type seems to make sense.
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ricardomaraschini, sttts The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@ricardomaraschini: Some pull requests linked via external trackers have merged: The following pull requests linked via external trackers have not merged: These pull request must merge or be unlinked from the Bugzilla bug in order for it to move to the next state. Bugzilla bug 1878040 has not been moved to the MODIFIED state. DetailsIn 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. |
As it is stated on OperatorSpec.LogLevel documentation valid values for the type LogLevel are Normal, Debug, Trace and TraceAll. Adding pattern validation for the LogLevel type seems to make sense.
This affected multiple CRDs, not sure if we can simply enforce this here or what would be the right approach to make sure all other operators comply with them. Other than that I am not sure these validations were omitted on purpose due some unknown reason.