+++ This bug was initially created as a clone of Bug #1805133 +++ Description of problem: Create alert receiver from console, user could create receivers with same name, and routing labels shown on list is a combination of routing labels from all these receivers. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Create slack type alert receiver with name "test1" and routing label "test=one". 2.Create webhook type alert receiver with name "test1" and routing label "new=two" 3.Delete one receiver "test1" by clicking "Delete Receiver" in kebab. Actual results: 1. Receiver "test1" is created. 2. Another receiver "test1" is created, and routing label for both "test1" receiver are "test=one new=two" 3. All receivers named "test1" are deleted. Expected results: 2. Not sure if it's legal to have receivers with same name. 3. If receivers with same name could co-exist, should not delete all receivers when delete one of them. Additional info: --- Additional comment from David Taylor on 2020-02-21 14:45:37 UTC --- I suggest we wait on implementing a whole bunch of UI/frontend receiver form validations. The issue is that other k8s yaml is validated via the backend, since the alertmanger.yaml is stored in a Secret, it currently doesn't go through any yaml validation. There is a JIRA story to investigate an overall alertmanger yaml schema validation strategy: https://issues.redhat.com/browse/CONSOLE-2048 In the JIRA story, Sam P. mentions: ".. the monitoring guys are probably going to move [alertmanager] to a CRD in 4.5 if they do, we'd have the backend to validate for us so i'd probably hold off on [implementing more frontend validation]". --- Additional comment from David Taylor on 2020-02-21 16:35:26 UTC --- Receiver's names should be unique: # The unique name of the receiver. name: <string> https://prometheus.io/docs/alerting/configuration/#receiver After some discussions it was determined that this will be fixed in console UI. We do not know when/if monitoring team will switch alertmanager to a CRD, so until such time console will handle alertmanager.yaml validations.
Dropping this down to low. We have a PR opened against 4.5 with something in flight, but should not block release on a validation issue. Nice to have.
Checked on OCP 4.4 with payload 4.4.0-0.nightly-2020-03-05-194612. Steps to verify: 1. Create slack type alert receiver with name "test", could create successfully. 2. Create webhook type alert receiver with name "test", there is prompt info "A receiver with that name already exists." and "Create" button is disabled. The bug is fixed, so move it to "Verified".
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0581