fix(k8s): fix scope assignment to the resource

[lukidzi]

Motivation

While working on another issue I noticed that we incorrectly set the scope for Kubernetes CRDs.

Implementation information

When isNamespaced set scope Namespaced

[github-actions]

Reviewer Checklist

🔍 Each of these sections need to be checked by the reviewer of the PR 🔍:
If something doesn't apply please check the box and add a justification if the reason is non obvious.

• Is the PR title satisfactory? Is this part of a larger feature and should be grouped using > Changelog?
• PR description is clear and complete. It Links to relevant issue as well as docs and UI issues
• This will not break child repos: it doesn't hardcode values (.e.g "kumahq" as an image registry)
• IPv6 is taken into account (.e.g: no string concatenation of host port)
• Tests (Unit test, E2E tests, manual test on universal and k8s)
  • Don't forget ci/ labels to run additional/fewer tests
• Does this contain a change that needs to be notified to users? In this case, UPGRADE.md should be updated.
• Does it need to be backported according to the backporting policy? (this GH action will add "backport" label based on these file globs, if you want to prevent it from adding the "backport" label use no-backport-autolabel label)

[Icarus9913]

2 Questions:

• If we changed the +kubebuilder:resource:scope=Namespaced marker, we need to generate the new k8s CRD yaml right?
• Do we need to touch the legacy policies?

[lukidzi]

If we changed the +kubebuilder:resource:scope=Namespaced marker, we need to generate the new k8s CRD yaml right?

I don't think we need to generate new CRD the scope change touches only <LegacyPolicy>List which I belive it's not CRD only <LegacyPolicy> is a CRD

Do we need to touch the legacy policies?

The error was only here

[lahabana]

This change has no other side effects? Interesting...

[lahabana]

I don't think we need to generate new CRD the scope change touches only List which I belive it's not CRD only is a CRD

Is it maybe unecessary then?

[lukidzi]

I feel that these functions are used in kube clients for .List(), but there is no corresponding CRD for them. I wanted to keep it consistent. Additionally, if we later need to check whether an object is namespace-scoped or cluster-scoped for some operation, the current approach might return incorrect results (though only at the code level).

[lahabana]

Do we need these annotations yes or no?

[lukidzi]

Do we need these annotations yes or no?

No, we don't

https://kubernetes.io/docs/reference/using-api/api-concepts/#collections

Keep in mind that the Kubernetes API does not have a kind named List.

kind: List is a client-side, internal implementation detail for processing collections that might be of different kinds of object. Avoid depending on kind: List in automation or other code.

[Icarus9913]

OK, it's *List. So the comment marker would not impact the CRD, you're right.