kuryr-conroller and cni should igore system k8s resource

[QingchuanHao]

If a pod in kube-system is deleted, kuryr-cni and kuryr-controller will get the notification and allocated thread from pool to handler the event, But kuryr-controller and kuryr-cni care only about tenant-created resources, not system ones. So it's reasonable to ignore event of system namespaces.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/552873

[Eunsoo Park (esevan.park)]

Hello, QingchuanHao.

Could you explain why the resources in kube-system should be ignored?
As a simple example, Prometheous pod which is used in a very common use case is usually created in kube-system.
How it could be created unless kuryr-kubernetes watches pods in kube-system?

Thanks.

[QingchuanHao (haoqingchuan-28)]

Thank your comment, Eunsoo Park.

I also share some questions here:

Kubernetes should be deployed by neutron network, or by administrator?

If Kubernetes use neutron to establish the system network, then some tenant should be allocated for system network, seperatedly to other tenant resources? But it seems there is no "controller" on kubernetes to manage Kuberentes system pods.

If kubernetes is deployed by administor, apart from neutron, then tenant-created pod, e.g. Prometheous should be able to reach kubernetes system pod, and it needs to allow physical network for kerbernetes system network reach neutron tenant network pass.

Maybe after answering these question, we can address your question :)

[Irena Berezovsky (irenab)]

I think that handling of the port Add/Remove events should be handled according to the Pod network owner. As long as we support single network owner, kuryr should be handling the events. Once there are multiple network providers as it is currently discussed by k8s-net-sig team, it should be only kuryr destined Pods

[OpenStack Infra (hudson-openstack)]

Change abandoned by Antoni Segura Puimedon (<email address hidden>) on branch: master
Review: https://review.openstack.org/552873
Reason: Lack of activity