Bug 1804777

+++ This bug was initially created as a clone of Bug #1804049 +++

Description of problem:
User create Alert receiver with multiple routing label.
When 2 pairs of routing label have same key, it only shows latest one on list page. But if one of them use regular expression, detail page separate them as 2 pairs. If both of them are using/not using regular expression, the first one is replaced by second one.

Version-Release number of selected component (if applicable):
4.4.0-0.nightly-2020-02-16-205302

How reproducible:
Always

Steps to Reproduce:
1. User create Alert receiver from alertmanager with multiple routing labels.
User have 2 pairs of routing labels with same key, both are using regular expression (or both are not). Check on list page and Edit form page.
2. User have 2 pairs of routing label with same key, one is using regular expression, the other doesn't. check list and detail page.
3. Create pairs of routing label with different label


Actual results:
1. Both list page and detail page only show the 2nd one, the 1st one is replaced.
2. List page only shows the regular expression pair. Detail page show both, but it reorders the regular expression pair as latest pair.
3. It only display as one pair of label, using comma to separate them.

Expected results:
1&2. Both list and detail page should be consistent. Either labels with same key should be replaced to the latest one no matter using regular expression or not. Or the one using regular expression and the other which not using it should be separated, list page should show as separated one as well.
3. Display for separated labels need to display as 2 individual label. 

Additional info:

--- Additional comment from David Taylor on 2020-02-18 19:24:31 UTC ---



--- Additional comment from David Taylor on 2020-02-18 19:26:18 UTC ---



--- Additional comment from David Taylor on 2020-02-18 19:49:13 UTC ---

- Cannot have same keys in single block (see attachment 1663882 [details])
- When checking 'Regular Expression' checkbox, label key-values are saved to different block than non-regex labels (see attachment attachment 1663883 [details])

I see two issues:

a) In the case where one has saved Routing labels like: "severity: warning [ ]Regular Exp." and "severity: ^err$ [X]Regular Exp." (which is valid, but I'm not sure logical given Alertmanagers AND'ing of route labels), the list page should show both labels -this is a bug

b) Handling Same Keys - the code does reduce to unique keys per 'match' and 'match_re' yaml blocks.  I recommend adding a validation to the Route Label Editor which highlights duplicate route label keys per regex and non-regex label sets.  Not sure how logical/typical this usecase is though, would user enter 'severity: warning' and 'severity: error' labels thinking it was an OR situation (labels are AND'ed).  Currently, I believe 'severity: error' would only be saved.

--- Additional comment from David Taylor on 2020-02-18 22:24:38 UTC ---

I have a fix for (a) list page showing same key for regex and non-regex routing labels.

irt. (b) Handling Same Keys - The instructions on the page say "Firing alerts with labels that match -->ALL<-- of these selectors...' so would a user logically create 'severity: warning' and 'severity: error' labels knowing an alert can never match these conditions?  If so, should be validate for this, or are we ok with just saving single 'severity: error' label.  I can look into validation, but it's complicated by the fact that the Route Label Editor is multi-rowed and we need to validate sets of labels (regex, non-regex).

--- Additional comment from David Taylor on 2020-02-18 22:30:32 UTC ---

Similarly, a user can create "severity: warning [ ]Regular Exp."(non-regex) and "severity: ^info$ [X]Regular Exp." (regex w/ same key) which will be saved as separate routing labels, but logically the non-regex would need to/could be included in the regex label (due to ANDing). 

A simpler validation would be to just to make sure all routing labels are unique between non-regex(match) and regex (match_re) labels, even though technically you could have same keys in a regex and a non-regex label.  idk, it's complex :-)

--- Additional comment from XiaochuanWang on 2020-02-19 01:53:13 UTC ---

Thanks David! Plz feel free to rephrase this bug since it includes different scenarios and complex logic.