configuration: Implement IsZero for relabel.Regex to remove default regex#14004
Conversation
… regex field if it was not provided in the first place Signed-off-by: Liam Howe <[email protected]>
|
This seems workable, but I was rather confused for a while. I was unfamiliar with the Having got that deep into the workings, I discovered an alternative approach: since the field is declared as |
Signed-off-by: Liam Howe <[email protected]>
|
@bboreham Thanks for reviewing, this is good to know and I agree that the |
Thanks for the review @bboreham! I don't have permissions to merge, will this PR be merged by someone else? |
|
Yes I can merge, was just waiting to see if anyone else had a view. |
There was a problem hiding this comment.
lgtm, thanks.
Not related to the PR:
Even though we have a default regex, I don't see why we fallback on the empty regex here
prometheus/model/relabel/relabel.go
Lines 102 to 110 in 4b7a44c
Also empty regex is marshalled differently
prometheus/model/relabel/relabel.go
Lines 201 to 206 in 4b7a44c
null"
|
|
||
| // IsZero implements the yaml.IsZeroer interface. | ||
| func (re Regexp) IsZero() bool { | ||
| return re.Regexp == DefaultRelabelConfig.Regex.Regexp |
There was a problem hiding this comment.
I assume this takes into account cases where the default (.*) regex is explicitly provided, as we compare pointers here.
It'd be great to have a regression test for it though.
There was a problem hiding this comment.
Good suggestion, I have added a test case for the default regex being explicitly provided, thanks.
There was a problem hiding this comment.
The test shows that this change is not good... Because the input and the marshalled should be different then
There was a problem hiding this comment.
I'm not sure I follow, if the regex is not provided in the original yaml, then when we unmarshal and marshal again it will still not be in the resulting yaml. If the default regex is explicitly provided then when we unmarshal and marshal it will still be there explicitly in the yaml, is that not expected?
Signed-off-by: Liam Howe <[email protected]>
|
I think the last test is wrong and should error. We might just call String() to compare the regexes. |
|
@roidelapluie the whole idea of this PR is to avoid comparing the regexp as a string, since "never set" and "set to a string equal to the default" are not the same. |
|
I tried to reach @roidelapluie out of band. Let's wait for another day or so if he comes back to us with an explanation. Otherwise, we have to assume @bboreham and @machine424 are right and this is the way to go. |
|
OK, let's move forward with this. |
Fixes #12534
Currently, when unmarshalling some relabel config from YAML, if the regex field is not provided we set this to be equal to the default value. If we then want to marshal this config back in to YAML, it will generate the YAML with the regex field set equal to the default YAML value, meaning that unmarshalling and then marshalling again doesn't give the same output as the original input. For the
keepequalanddropequalactions we expect that noregexfield is set and therefore an error is returned if we try to unmarshal, then marshal and again unmarshal one of these actions, because theregexfield will be set on the marshal step. By implementing the MarshalYAML function and ensuring theregexfield is not set if it was not provided originally, we fix this bug.