Adding @yeya24 to determine how much trouble it would cause for Thanos to rename those relabeling config JSON export fields to their original snake_case versions again.

Hello,

I do believe this would cause breakage.

We could have a (pseudo-code, not tested):

type RelabelStep struct {
    Rule   relabelConfigV2 `json:"rule"`
    Output labels.Labels   `json:"output"`
    Keep   bool            `json:"keep"`
}

type relabelConfigV2 struct {
    SourceLabels []string `json:"source_labels,omitempty"`
    Separator    string   `json:"separator,omitempty"`
    Regex        string   `json:"regex,omitempty"`
    Modulus      uint64   `json:"modulus,omitempty"`
    TargetLabel  string   `json:"target_label,omitempty"`
    Replacement  string   `json:"replacement,omitempty"`
    Action       string   `json:"action,omitempty"`
}

in the API response and do something like:

func (api *API) targetRelabelSteps(r *http.Request) apiFuncResult {
    ...
    for i, rule := range rules {
        outLabels, keep := relabel.Process(lbls, rules[:i+1]...)

        steps[i] = RelabelStep{
            Rule:   convertRelabelConfigV2(rule),
            Output: outLabels,
            Keep:   keep,
        }
    }

    return apiFuncResult{&RelabelStepsResponse{Steps: steps}, nil, nil, nil}
}

func convertRelabelConfigV2(rule *relabel.Config) *relabelConfigV2 {
    return &relabelConfigV2{
        SourceLabels: rule.SourceLabels,
        Separator:    rule.Separator,
        Regex:        rule.Regex.String(),
        Modulus:      rule.Modulus,
        TargetLabel:  rule.TargetLabel,
        Replacement:  rule.Replacement,
        Action:       string(rule.Action),
    }
}

I am not a great fan of that mix between both, but I like the new API to use snake_case, but dislike breaking API stability promises...

@roidelapluie Yeah, I had a copy of the relabel config struct in my standalone Relabeler tool for similar reasons. But I think this kind of duplication and field transfer is always a bit annoying and brittle, especially if someone forgets to update both versions when there's a change.

I am not a great fan of that mix between both, but I like the new API to use snake_case, but dislike breaking API stability promises...

In terms of breakage, I think this should not affect Prometheus itself, as I don't think any of our APIs returns relabel configs in JSON format. The JSON serialization was only added by @yeya24 a year ago in #15383 because Thanos wanted to store the relabel configs in their Thanos metadata files. But I'm wondering if Thanos could deal with this instead of having to bake the duplication into the Prometheus codebase.

Oh I see. That should be fine then, pending @yeya24's answer.

Would love to get your help @yeya24!

Thanks everyone - I'd say let's give this 3 more days to check for any response from @yeya24, after which I'd just merge it. I think keeping the field names the same between JSON + YAML is good, and Thanos should be able to manage the change somehow, or in the worst case we can still revert things.

@juliusv would you like to merge?

Thanks for reminding me - will merge :)