Using `schema.GroupKind` instead of Kind when determining object types
What happened: Now we determine the object types only by their kind, but sometimes different groups shared with same kind could have a conflict. Here is some reference code here:
https://github.com/karmada-io/karmada/blob/4d9b23ff729a5f8b41263d24a389c48c59a6d69a/pkg/resourceinterpreter/defaultinterpreter/prune/prune.go#L62
https://github.com/karmada-io/karmada/blob/4d9b23ff729a5f8b41263d24a389c48c59a6d69a/pkg/estimator/server/replica/replica.go#L35-L36
https://github.com/karmada-io/karmada/blob/4d9b23ff729a5f8b41263d24a389c48c59a6d69a/pkg/resourceinterpreter/defaultinterpreter/prune/prune.go#L53
I suppose that it's better to use GroupVersionKind().GroupKind() to replace these judgement.
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:
- Karmada version:
- kubectl-karmada or karmadactl version (the result of
kubectl-karmada versionorkarmadactl version): - Others:
https://github.com/karmada-io/karmada/blob/master/pkg/util/constants.go#L74
those constants in above file seem all be used, if we replace corresponding codes, there are a lot of files that need to be changed.
Exactly, this is a heavy work.
Yes, it makes sense.
@Garrybest is this a beginner-friendly issue.
I think it's easy but a little bit treadmill, would you like to have a try?😄
@Garrybest I would, my main goal is to learn.
@Garrybest will you give me a little more insight on this? It would be very helpful.
In constants.go, you will see a lot of string constants which reprent Kind of Kubernetes object. However, a Kind does not represent the type of resources because different APIs may have the same Kind but different APIVersion. So different groups shared with same kind could have a conflict.
So I think the only way we distinguish the categories is to ensure a identical Group and Kind. So I'd like to tranmute these constants as schema.GroupKind, which could be generated by pkg SchemeGroupVersion var, like appsv1.SchemeGroupVersion.WithKind(kind).GroupKind(). So that we compare GroupKind instead of Kind under all circumstances such as my description above.
Hi @johurul000, are you still interested in solving this issue? If you are busy, I'd like to push this issue forward. :)
@Poor12 go ahead
I think it's a kind of cleanup. /remove-kind bug /kind cleanup /help
@RainbowMango: This request has been marked as needing help from a contributor.
Please ensure the request meets the requirements listed here.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.
In response to this:
I think it's a kind of cleanup. /remove-kind bug /kind cleanup /help
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
/assign
I'm trying to figure out which PR/Issue should be included in the coming v1.7 release which is planned at the end of this month. I guess we don't have enough time for this feature, so I'm moving this to v1.8.