Peerpodconfig removal

[bpradipt]

This PR removes peerpodconfig controller and instead moves its functionality of advertising node extended resources for peerpods to CAA daemonset itself.

[stevenhorsman]

This seems like a great change in terms of removing code and simplifying things. Do you see any negatives of have the functionality integrated?
I had question from me about the limit default value and I guess we'll need a follow-up operator PR to reflect the removal as well?
Thanks!

[mkulke]

nit about the number of peerpods per node, other lgtm

[bpradipt]

This seems like a great change in terms of removing code and simplifying things. Do you see any negatives of have the functionality integrated?
I had question from me about the limit default value and I guess we'll need a follow-up operator PR to reflect the removal as well?

I strongly feel our default deployments should include webhook deployment along with the limit/node. Further hardening the resource management aspects as we move towards 1.0.
Operator PR will be next to remove peerpodconfig.

@mkulke @stevenhorsman what do you prefer as a good default for the number of peerpods per node?

[stevenhorsman]

LGTM. Thanks

[bpradipt]

Rebased and pushed, to trigger the e2e CI again.

[bpradipt]

The libvirt e2e test got killed due to the time it took.
As for the govulncheck, there is a vulnerability report for gob.Decoder.Decode. Wonder if we should wait for dependabot alerts and handle it accordingly.

@stevenhorsman @mkulke any thoughts?

[stevenhorsman]

The libvirt e2e test got killed due to the time it took. As for the govulncheck, there is a vulnerability report for gob.Decoder.Decode. Wonder if we should wait for dependabot alerts and handle it accordingly.

@stevenhorsman @mkulke any thoughts?

If we need to bump to 1.22.7 for this fix:

Vulnerability #1: GO-2024-3106
    Stack exhaustion in Decoder.Decode in encoding/gob
  More info: https://pkg.go.dev/vuln/GO-2024-3106
  Standard library
    Found in: encoding/[email protected]
    Fixed in: encoding/[email protected]

I'm not sure if dependabot will do this as it bumps packages rather than the go version? I'm happy for this to merge without that fix as then if dependabot hasn't created anything by Monday I can manually bump and try things out?

[bpradipt]

The libvirt e2e test got killed due to the time it took. As for the govulncheck, there is a vulnerability report for gob.Decoder.Decode. Wonder if we should wait for dependabot alerts and handle it accordingly.
@stevenhorsman @mkulke any thoughts?

If we need to bump to 1.22.7 for this fix:

Vulnerability #1: GO-2024-3106
    Stack exhaustion in Decoder.Decode in encoding/gob
  More info: https://pkg.go.dev/vuln/GO-2024-3106
  Standard library
    Found in: encoding/[email protected]
    Fixed in: encoding/[email protected]

I'm not sure if dependabot will do this as it bumps packages rather than the go version? I'm happy for this to merge without that fix as then if dependabot hasn't created anything by Monday I can manually bump and try things out?

I didn't read that the vulnerability is in go standard library. So we will need to bump golang.

I will merge this and open a new PR to bump golang version across the project

[bpradipt]

Working on the PR to update golang - #2030