New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix ClusterGroup realization status logic #3030
Conversation
Codecov Report
@@ Coverage Diff @@
## main #3030 +/- ##
==========================================
+ Coverage 60.93% 61.02% +0.09%
==========================================
Files 292 292
Lines 24708 24721 +13
==========================================
+ Hits 15056 15087 +31
+ Misses 8015 7993 -22
- Partials 1637 1641 +4
Flags with carried forward coverage won't be shown. Click here to find out more.
|
4fbf1cf
to
1281e30
Compare
| @@ -202,6 +202,10 @@ type NetworkPolicyController struct { | |||
| // concurrent access during updates to the internal NetworkPolicy object. | |||
| internalNetworkPolicyMutex sync.RWMutex | |||
|
|
|||
| // internalGroupMutex protects the internalGroupStore from current access | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
concurrent.
Why the mutex is needed? internalGroupStore itself is thread-safe. You may want to prevent race condition between the event handlers and syncWorkers but the critical sections in this commit only protects the store operations, which is duplicate with the lock in the store itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the reminder. Removed the group mutex
Signed-off-by: Yang Ding <dingyang@vmware.com>
1281e30
to
df9dad9
Compare
|
/test-all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Signed-off-by: Yang Ding <dingyang@vmware.com>
Fixes #3002.
ClusterGroup with child groups should only be considered groupMembersComputed after all its child groups are created and processed.
Signed-off-by: Yang Ding dingyang@vmware.com