Use WaitAndGetVNID() instead of GetVNID() when initializing network policy plugin on the node #13666
Conversation
|
@openshift/networking @danwinship PTAL |
|
Similar issue: #13265 |
If we're going to use WaitAndGetVNID in this case (and maybe #13265 suggests we have to?) then should we just get rid of the non-waiting version? It seems like it's basically never safe... (Longer term it might be nicer to have a smarter EventQueue that can delay telling us about Pod/Service/NetworkPolicy/EgressNetworkPolicy events until their corresonding NetNamespace exists. Then we don't have to worry about the watcher threads blocking waiting for netids.) |
…olicy plugin on the node If a new namespace was created after vnid population and before listing namespaces in initNamespaces()[networkpolicy.go], GetVNID() could fail. Similar case after listing policies in initNamespaces(). Using WaitAndGetVNID() may not fix the issue but will alleviate the problem. GetVNID() is not used expect vnids_node.go and may not be used elsewhere due to the above reasons. So renamed GetVNID() to getVNID().
pravisankar
force-pushed
the
fix-vnid-fetch-networkpolicy
branch
from
bf073a6 to
0b3e24b
Compare
|
@danwinship Long term we could do either smarter EventQueue or some way to embed VNID annotation on Namespace before persisting the object. |
|
LGTM |
|
[merge] |
|
Evaluated for origin merge up to 0b3e24b |
|
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_origin/313/) (Base Commit: dec90cf) (Image: devenv-rhel7_6134) |
If a new namespace was created after vnid population and before listing namespaces in initNamespaces()[networkpolicy.go],GetVNID() could fail. Similar case after listing policies in initNamespaces().
Using WaitAndGetVNID() may not fix the issue but will alleviate the problem.