Continuing the discussion from:
#4001 (comment)

Ah, yes correct. This PR changes MatchLabelSelectors to be handled in kube-apiserver when Pod is created.
So, existing objects will continue to have the labelselector made by MatchLabelSelectors even after the feature gate is turned off.

What is the ideal action here? OK to leave the existing objects when turning off the feature gate (as long as we state in KEP), or we somehow need to ignore the labelselector made by MatchLabelSelectors (gonna be tricky though..)?

Yes - I'm fine with leaving the existing objects as is [in fact we don't really have good mechanisms to do anything smarter].

Just please extend the Downgrade section with explanation about:

• leaving the existing objects as is
• scheduler ignoring this field when FG is disabled (even if set)
• IIUC, also scheduler depends on the FG, so please update the first question in PRR

Once all of the above is applied, this seems good to go for Alpha (IIUC we're only targeting Alpha now)

OK, thanks for clarifying.

scheduler ignoring this field when FG is disabled (even if set)
IIUC, also scheduler depends on the FG, so please update the first question in PRR

Regarding them, No.
The kube-apiserver generates LabelSelector from MatchLabelSelectors and kube-scheduler computes PodAffinity/PodAntiAffinity as it does now. So, kube-scheduler doesn't look at MatchLabelSelectors directly and it doesn't depend on the feature gate. (instead, it just looks at LabelSelector generated from kube-apiserver.)

Actually, I have an additional question: IIUC, PodAffinity/PodAntiAffinity is immutable, right? So once I create pod, I can no longer change that, right?

If the above is true, we should clarify that:

• if FG is disabled, MatchLabelSelectors will be dropped for newly created pods and for existing pods
• if FG is disabled, MatchLabelSelectors and changes to LabelSelector propagated from it will remain as they are for already existing pods

Yes, right. Sure, let me clarify more on the KEP.

c641305

If FG is disabled,

• for Pod creation, pods with MatchLabelSelectors will be rejected in validation.
• for Pod update (= for existing Pods), pods with MatchLabelSelectors will not be rejected, it'll remain as it is.

Does it sound good?

nit: Scheduling of newly created pods with MatchLabelSelector set is affected.
All already existing pods are unafected.

I'm still keen on using two slice to represent the semantics, to avoid another "selector" field to confuse with existing labelSelector. How about:

type PodAffinityTerm struct {
    matchLabelKeys []string
    mismatchLabelKeys []string

where matchLabelKeys follows the same naming pattern and semantics with existing ones like:

https://github.com/kubernetes/kubernetes/blob/07646db483d0ee8c53e8292fb90b547fccb75eae/staging/src/k8s.io/api/core/v1/types.go#L3709

and mismatchLabelKeys is simply an opposite semantics of matchLabelKeys.

cc @ahg-g per #4001 (comment)

@msau42 what do you think?

Having matchLabelKeys and mismatchLabelKeys sounds good to me to match what's in podTopologySpread. We can continue discussing if there's a better field name later.

cc @alculquicondor

Sounds good to me; @sanposhiho can you please update the KEP? as @msau42 said, we can debate the names in the implementation PR.

OK, I'll update the KEP soon.

Can you update the kep.yaml with status: implementable here?

OK, I'll follow up in another PR