Description of problem

OpenShift informers like the ClusterOperator informer default to MetaNamespaceIndexFunc as their indexer, despite tracking cluster-scoped resources. MetaNamespaceIndexFunc mixes the nominal namespace and name into a key, regardless of whether the resources are cluster-scoped or namespaced.

This can apparently cause problems, when a client using these informers mistakenly pushes a nominally-namespaced resource into the informer. The informer cache then holds a copy of this nominally-namespaced resource forever (unless the client itself asks the informer to delete it), because the API-server will never set namespace on a cluster-scoped resource in the responses it serves to the informer. Possibly the entry would get cleared on each re-list?

Version-Release number of selected component (if applicable)

Reproduced both in 4.14 (OCPBUGS-27822) and in the 4.16/dev branch (reproducer in cluster-version-operator#1029).

How reproducible

Every time.

Steps to Reproduce

1. Set up an informer for a cluster-scoped resource.
2. Push a namespaced resource into the informer with a Create call.
3. List all resources with a List call.

Actual results

See both namespaced and non-namespaced versions of the resource.

Expected results

Only see non-namespaced versions of the resource.

Additional info

I dunno if the informer logic can tell before talking to the Kube API server that the resource is cluster-scoped or not, but it should be able to tell once it hears back about what the API-server thought about the request.

Alternatively, if any resources with that group/kind(/version?) in the store have an empty namespace, it's likely that all namespaced keys with that same GK(V?) can be dropped, and the namespace ignored for all future transactions as long as any empty-namespace GK(V?) entries exist in the store. Or some other way for the informer's cache to understand "this store is about cluster-scoped resources, where namespace is irrelevant".