@msau42 , I remembered that I had this check in the initial commit,
but you'd suggest that the things of TopologySelectorTerm should be same to that of NodeSelector as much as possible, so we removed it.

Now since it has already been kind of different from NodeSelector, let's add the check here?
An empty expression won't bring users anything I guess.

think carefully about whether we'd need to extend these with other types of matchers in the future (e.g. a field matcher like this:

if so, we'd need to tolerate len(term.MatchLabelExpressions) == 0 in validation now to make such a future addition safe for old skewed apiservers

What does the version skew issue look like? If a client makes a call to create a new object against an old apiserver, wouldn't it fail anyway because MatchFields doesn't exist?

I did explicitly call it MatchLabelExpressions to leave room for other types of matchers in the future (although no concrete use cases yet)

@liggitt can you describe more in detail the skew issue?

@liggitt can you describe more in detail the skew issue?

What is the behavior of a TopologySelectorTerm with no MatchLabelExpressions? I'd expect it to match nothing.

Making MatchLabelExpressions required makes it very hard to make it optional in the future without breaking clients that expect a required field to stay required.

Making it optional allows adding something like MatchFieldExpressions to TopologySelectorTerm in the future without breaking clients that assume that all TopologySelectorTerm objects will contain non-zero-length MatchLabelExpressions.

reflect.DeepEqual or semantic.DeepEqual? (reflect differentiates between nil and [], semantic does not)

Neat, in this case reflect.DeepEqual is OK but semantic.DeepEqual is safer. Will update

Can you also add some positive test cases similar to these negative ones? For example, specifying the same key but across different TopologySelectorTerms