MON-4025: Add AlertmanagerMainConfig#2148
MON-4025: Add AlertmanagerMainConfig#2148openshift-merge-bot[bot] merged 2 commits intoopenshift:masterfrom
Conversation
|
Hello @marioferh! Some important instructions when contributing to openshift/api: |
openshift-ci
bot
added
the
size/XXL
marioferh
force-pushed
the
alertmanager_monitoring_api
branch
from
c0d2965 to
c35227f
Compare
|
/hold |
openshift-ci
bot
added
the
do-not-merge/hold
everettraven
left a comment
everettraven
left a comment
There was a problem hiding this comment.
A lot of the comments are centered around godoc. I'd recommend looking at https://github.com/openshift/enhancements/blob/master/dev-guide/api-conventions.md#write-user-readable-documentation-in-godoc for more information on what makes a good godoc that is helpful to users.
Another thing that stood out was multiple fields related to pod spec configuration - you may want to group those into a separate struct to have a single field that clearly denotes that the sub-fields in that object map directly to pod spec fields.
openshift-merge-robot
added
the
needs-rebase
marioferh
force-pushed
the
alertmanager_monitoring_api
branch
4 times, most recently
from
450dd7b to
a6d7bc9
Compare
openshift-merge-robot
removed
the
needs-rebase
everettraven
left a comment
everettraven
left a comment
There was a problem hiding this comment.
Only got about halfway through the changes on this round, will circle back soon to review the rest.
marioferh
force-pushed
the
alertmanager_monitoring_api
branch
2 times, most recently
from
e062ce8 to
ee3b854
Compare
marioferh
force-pushed
the
alertmanager_monitoring_api
branch
2 times, most recently
from
b324126 to
d9fba48
Compare
everettraven
left a comment
everettraven
left a comment
There was a problem hiding this comment.
Another round of comments. Additionally, I would like to see tests added to ensure the API and validations you have are working as expected.
|
|
||
| // AlertmanagerContainerResources defines simplified resource requirements for a container. | ||
| type AlertmanagerContainerResources struct { | ||
| // cpu defines the CPU resource limits and requests. |
There was a problem hiding this comment.
Because not setting this could be harmful to the system, are there any defaults that we set on a users behalf?
| // | ||
| // When omitted, this means the user has no opinion and the platform is left | ||
| // to choose reasonable defaults. These defaults are subject to change over time. | ||
| // The current default is `- operator: "Exists"` which means that all taints are tolerated. |
There was a problem hiding this comment.
Is that safe? Not even an API question, but, tolerating all taints is generally not something we would do for control plane components. There are many valid taints (uninitialized for the CCM, network not ready) that I would expect this pod not to tolerate
There was a problem hiding this comment.
let me think about it
|
Continue tomorrow with last comments |
marioferh
force-pushed
the
alertmanager_monitoring_api
branch
3 times, most recently
from
d60f672 to
b758adf
Compare
everettraven
left a comment
everettraven
left a comment
There was a problem hiding this comment.
Another round of comments.
I'd also like to see some integration tests put in place to flex your validations and user workflows. https://github.com/openshift/api?tab=readme-ov-file#defining-api-validation-tests
| // This field is only effective when the user workload Alertmanager instance is not enabled. | ||
| // If the user workload monitoring Alertmanager is enabled, this field is ignored. | ||
| // Required: This field must be specified. | ||
| // Allowed values are Selectable and None |
There was a problem hiding this comment.
well I did selectable and none instead of enable or disable, correct?
Sure. We generally discourage using Enable/Disable for terminology in favor of something more meaningful in the context of the API.
If None and "" semantically mean the same thing, there isn't really a reason to have the None enum value.
For example, if None literally meant no user-defined configurations are processed and "" meant that the platform had some default namespace(s) it looked at for user-defined configurations then those would be semantically different and warrant having different values.
Also, what does Selectable mean? Does this mean I, as a user, can choose which namespaces Alertmanager will look at for user-defined configs?
|
#2148 (comment) |
Signed-off-by: Mario Fernandez <mariofer@redhat.com>
|
/retest-required |
1 similar comment
|
/retest-required |
|
/override ci/prow/verify-crd-schema Only incorrectly identified newly required fields (they have optional parents) |
|
/lgtm |
|
@JoelSpeed: Overrode contexts on behalf of JoelSpeed: ci/prow/verify-crd-schema 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-sigs/prow repository. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JoelSpeed, marioferh 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 |
|
/retest-required |
|
/retest-required |
1 similar comment
|
/retest-required |
|
/retest-required |
|
/test e2e-gcp |
|
/test okd-scos-e2e-aws-ovn |
|
@marioferh: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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-sigs/prow repository. I understand the commands that are listed here. |
|
/test okd-scos-e2e-aws-ovn |
1 similar comment
|
/test okd-scos-e2e-aws-ovn |
|
/test minor-e2e-upgrade-minor |
|
Minor upgrade seems to be affected by https://issues.redhat.com/browse/TRT-2190 /override ci/prow/minor-e2e-upgrade-minor |
|
@JoelSpeed: Overrode contexts on behalf of JoelSpeed: ci/prow/minor-e2e-upgrade-minor 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-sigs/prow repository. |
openshift-merge-bot
bot
merged commit e375905
into
openshift:master
ty |
|
[ART PR BUILD NOTIFIER] Distgit: ose-cluster-config-api |
marioferh
changed the title
7 participants
Every component will be in a separated PR in order to improve review process
First PR: #1929
Related: Enhancements Proposal openshift/enhancements#1627