Consider switching gopkg.in/yaml.* to github.com/goccy/go-yaml

[bwplotka]

Looks like gopkg.in/yaml.* project seems to be deprecated. Also v2 is EOL.

The https://github.com/goccy/go-yaml is being recommended, also by the author of gopkg.in/yaml. I checked briefly and it looks healthy and even more capable, especially around YAML marshal/unmarshal customizations.

Additional arguments for doing this is that this creates friction for client_golang users due to broken vuln scanners. client_golang don't use yaml marshal/unmarshal directly I believe, but we use common so we are impacted by scanners.

NOTE: This will stop impacting client_golang if stop importing common if that's even possible.

Anyway, even if not for client_golang users with broken scanners, it would be nice to upgrade Prometheus ecosystem going forward, assuming it's possible (PoC needed).

Kudos to @kakkoyun who surfaced this earlier on client_golang.

[matthiasr]

How will this affect what users can do in YAML files, especially around the less well defined aspects such as anchors?

[dgl]

@matthiasr if anything it looks like goccy has better support for anchors (e.g. pulling them in from other files -- I'm not sure we'd want to do things like that, as it seems closer to adding templating). We currently have issues in Prometheus due to the mix of yaml.v2 and yaml.v3 which means some operations like merge keys don't work, so switching to a library like this would likely fix some issues like that.

One concern I have for this is in prometheus itself there are places that yaml.Node is in the actual type it returns (e.g. rulefmt). I know we don't guarantee a stable Go API, but we would need to carefully coordinate any changes with downstream projects.

[dimitarvdimitrov]

We hit a serialize-then-deserialize incompatibility bug in yaml.v3 in grafana/mimir and was wondering if the prometheus system is planning a migration. The rulefmt dependency on yaml.Node shouldn't really affect mimir as a downstream project.

[aknuds1]

Has https://github.com/yaml/go-yaml been considered @bwplotka? It looks as if Kubernetes may be transitioning to it.

[kakkoyun]

Has https://github.com/yaml/go-yaml been considered @bwplotka? It looks as if Kubernetes may be transitioning to it.

This looks like how we should do this. Low effort migration.