Migrate from go yaml.v2 to yaml.v3

[antgamdia]

Description of the change

This PR simply updates a piece of code using the yaml version 2 instead of v3. Since it has some breaking changes, it is a separate PR.

Benefits

Avoid multiple dependency versions in our codebase.

Possible drawbacks

Some additional and unnoticed breaking changes? Let's see what the CI thinks.

Applicable issues

• rel Reduce same-purpose Go dependencies  #3848

Additional information

This is one of the few places we are using the go yaml library instead of the k8s one. In this piece of code, we don't have any typed model to marshal from/to, so I guess that's the reason.
However, I wonder about this decision, I mean, why not rely on a PodSpec since it is a well-established k8s API (corev1)?
Happy to discuss it offline in our standup, though.

[absoludity]

This is one of the few places we are using the go yaml library instead of the k8s one. In this piece of code, we don't have any typed model to marshal from/to, so I guess that's the reason.
However, I wonder about this decision, I mean, why not rely on a PodSpec since it is a well-established k8s API (corev1)?

I'm not 100% about "the" reason (it's been a while), but a post renderer takes a byte array of the generated manifests and returns a byte array of the mutated manifests. These are arbitrary yaml manifests, not specific pod specs or similar. But if there's a way to parse that with a typed parser and pull out just the pod specs, that'd be excellent. Perhaps a parser that just parses the standard metadata, then you can just deal with the know (typed) resources that you're interested in.

Happy to discuss it offline in our standup, though.

+1

[antgamdia]

But if there's a way to parse that with a typed parser and pull out just the pod specs, that'd be excellent. Perhaps a parser that just parses the standard metadata, then you can just deal with the know (typed) resources that you're interested in.

Thanks for the explanation!

As I mentioned in #4175 (comment), I wonder if using the built-in decoder in k8s UniversalDecoder() + DecodeInto(...) [1] would be useful here, haven't tried though.

[1] https://stackoverflow.com/a/63338697

[absoludity]

But if there's a way to parse that with a typed parser and pull out just the pod specs, that'd be excellent. Perhaps a parser that just parses the standard metadata, then you can just deal with the know (typed) resources that you're interested in.

Thanks for the explanation!

As I mentioned in #4175 (comment), I wonder if using the built-in decoder in k8s UniversalDecoder() + DecodeInto(...) [1] would be useful here, haven't tried though.

[1] https://stackoverflow.com/a/63338697

Hmm, maybe? Haven't played with it, but DecodeInto is the typed version, which assumes you know the type which the post-processor doesn't. There is also there Object.Decode, but then you're back with a non-typed object. Universal decoder might be removed, but could help - not sure. But yep, happy if there's a better way to do so with these.