Skip to content

Comments

Allow empty matchers#1289

Merged
stuartnelson3 merged 10 commits intomasterfrom
allow-empty-matchers
Mar 21, 2018
Merged

Allow empty matchers#1289
stuartnelson3 merged 10 commits intomasterfrom
allow-empty-matchers

Conversation

@w0rm
Copy link
Member

@w0rm w0rm commented Mar 16, 2018

@stuartnelson3 I changed the parser to allow empty matchers, I also removed the validation rule for empty matcher values in the silence form. Right now I am getting errors from the backend when I submit empty matchers:

screen shot 2018-03-16 at 11 16 53

screen shot 2018-03-16 at 11 17 31

Relates to #1240

@w0rm w0rm requested a review from stuartnelson3 March 16, 2018 10:30
@stuartnelson3
Copy link
Contributor

Awesome, thanks for doing this. The backend errors are expected, and will be fixed now that I know about the correct empty matcher behavior. I'll add that to this PR.

@stuartnelson3
Copy link
Contributor

@w0rm backend code should be working now. I think we can remove the stringNotEmpty validation on the matcher values in the front end on the silence form, since that's preventing creation of silences with empty matchers. Right?

@w0rm
Copy link
Member Author

w0rm commented Mar 20, 2018

@stuartnelson3 I've already done that in my pr. Check the changes to ui/app/src/Views/SilenceForm/Types.elm

@stuartnelson3
Copy link
Contributor

we're inconsistent in how we are searching for alerts between the alert list view and the alert preview on the silence form. When updating the filter bar in the alert list view, the filter query string has curly braces filter={foo%3D"bar"}, while on the silence form there are no curly braces filter=foo="bar",baz="". Would be good to make this consistent (trying to look now)

@stuartnelson3
Copy link
Contributor

Changes also needed to be made here:

diff --git a/ui/app/src/Views/SilenceForm/Types.elm b/ui/app/src/Views/SilenceForm/Types.elm
index da09c31..e098a10 100644
--- a/ui/app/src/Views/SilenceForm/Types.elm
+++ b/ui/app/src/Views/SilenceForm/Types.elm
@@ -204,7 +204,7 @@ fromMatchersAndTime defaultCreator matchers now =
 appendMatcher : MatcherForm -> Result String (List Matcher) -> Result String (List Matcher)
 appendMatcher { isRegex, name, value } =
     Result.map2 (::)
-        (Result.map2 (Matcher isRegex) (stringNotEmpty name.value) (stringNotEmpty value.value))
+        (Result.map2 (Matcher isRegex) (stringNotEmpty name.value) (Ok value.value))
 
 
 filterMatcherToMatcher : Utils.Filter.Matcher -> Maybe Matcher
diff --git a/ui/app/src/Views/SilenceForm/Updates.elm b/ui/app/src/Views/SilenceForm/Updates.elm
index 137a5ff..0113f3b 100644
--- a/ui/app/src/Views/SilenceForm/Updates.elm
+++ b/ui/app/src/Views/SilenceForm/Updates.elm
@@ -158,7 +158,7 @@ updateForm msg form =
             let
                 matchers =
                     Utils.List.replaceIndex index
-                        (\matcher -> { matcher | value = validate stringNotEmpty matcher.value })
+                        (\matcher -> { matcher | value = matcher.value })
                         form.matchers
             in
                 { form | matchers = matchers }

@w0rm
Copy link
Member Author

w0rm commented Mar 20, 2018

@stuartnelson3 oh, sorry, I missed that. Thanks!

The same behavior exists in prometheus. This is a
bit superfluous, but in the event people are using
old versions of prometheus or a different metric
gathering system, it's still valid to check.
Copy link
Contributor

@stuartnelson3 stuartnelson3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The elm code looks good, since I wrote the go code there'll have to be another reviewer.

api/api.go Outdated
v, prs := sms[m.Name]
switch m.Type {
case labels.MatchNotEqual, labels.MatchNotRegexp:
case labels.MatchNotRegexp:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't think of a "clever" way to do this, and didn't want to nest a bunch of if statements. Any suggestions are welcome, but this is pretty clear to read so I'm ok with it.

@stuartnelson3
Copy link
Contributor

@brancz do you have a chance to review the go code in this PR?

api/api.go Outdated
switch m.Type {
case labels.MatchNotEqual, labels.MatchNotRegexp:
case labels.MatchNotRegexp:
if string(m.Value) == "^(?:)$" && prs {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The string(m.Value) == "^(?:)$" test seems brittle to me. Also this will break if we update the vendored github.com/prometheus/prometheus/pkg/labels package because in the latest version, the original m.Value is kept (no anchoring added, see this). Maybe updating github.com/prometheus/prometheus/pkg/labels and matching againt "" then?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, 100%. Good to hear that the latest version doesn't change m.Value, will update that and simplify this.

@stuartnelson3
Copy link
Contributor

@simonpasquier if you have time, feel free to review the code further :)

@simonpasquier
Copy link
Member

LGTM

@stuartnelson3 stuartnelson3 merged commit a578319 into master Mar 21, 2018
@stuartnelson3 stuartnelson3 deleted the allow-empty-matchers branch March 21, 2018 13:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants