ignore kube-system, openshift and other non-user namespaces

[phoracek]

There are some namespaces we should ignore during the admission. Especially system namespaces should not rely on KubeMacPool stability.

[SchSeba]

Thanks for opening this issue.

I am not sure what is the best approach to take care of this, I was able to think on one that is to run on namespaces like kube-system and openshift-* and add them the kubemacpool/ignoreAdmission label.

I wasn't able to find a pre configured label on this namespaces

kubectl get ns kube-system -o yaml

apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: 2019-07-22T14:44:27Z
  name: kube-system
  resourceVersion: "9"
  selfLink: /api/v1/namespaces/kube-system
  uid: 34c2dc75-ac8f-11e9-ae51-525500d15501
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

[phoracek]

Yeah, the missing label is a problem. And labelling those ourselves sounds little unclean. But maybe it's better than just blocking the whole system.

Could you at least check openshift, does it have any labels on its kube-system?

[SchSeba]

@phoracek on openshift we only have annotations

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/sa.scc.mcs: s0:c17,c4
    openshift.io/sa.scc.supplemental-groups: 1000280000/10000
    openshift.io/sa.scc.uid-range: 1000280000/10000
  creationTimestamp: "2019-07-22T07:49:18Z"
  name: kube-system
  resourceVersion: "9333"
  selfLink: /api/v1/namespaces/kube-system
  uid: 35aec22e-ac55-11e9-ab52-664f163f5f0f
spec:

but again not labels.

you think it's a good solution to add labels by the operator I am really not sure?

[phoracek]

Maybe we can follow the opposite way. Administrator has to create NetworkAttachmentDefinitions per each namespace to make them available for users. If the admin wants to enable KubeMacPool, they have label the namespace appropriately. This will need further discussion, but I think it would be fair. Also it would give us an easy way to disable it in case something goes wrong.