-
Notifications
You must be signed in to change notification settings - Fork 369
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
Support for batch OVS flow updates #844
Conversation
Thanks for your PR. The following commands are available:
These commands can only be run by members of the vmware-tanzu organization. |
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.
I only reviewed the commit of batch update, though not finished too.
4c52c27
to
ef7c13e
Compare
Thanks for your PR. The following commands are available:
These commands can only be run by members of the vmware-tanzu organization. |
5ed4ccb
to
c3b9e96
Compare
ef9112b
to
78243a2
Compare
/test-all |
pkg/agent/openflow/network_policy.go
Outdated
@@ -711,21 +711,41 @@ func (c *policyRuleConjunction) getAddressClause(addrType types.AddressType) *cl | |||
// If there is an error in any clause's addAddrFlows or addServiceFlows, the conjunction action flow will never be hit. | |||
// If the default drop flow is already installed before this error, all packets will be dropped by the default drop flow, | |||
// Otherwise all packets will be allowed. | |||
func (c *client) InstallPolicyRuleFlows(ruleID uint32, rule *types.PolicyRule, npName, npNamespace string) error { | |||
func (c *client) InstallPolicyRuleFlows(ofPolicyRule types.OFPolicyRule) error { |
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.
Is it better to flow the workflow of BatchInstallPolicyRuleFlows? I mean we don't need to implement two workflows.
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.
I intentionally kept those two workflows separate. The reason is:
- For
InstallPolicyRuleFlows
, the conjMatchFlowLock is needed to protect from concurrency issues. This lock is not needed for batch install because the rules will be processed in sequence. - For
BatchInstallPolicyRuleFlows
, for each rule it is processing, as soon as the context changes are calculated, ctxChange.updateContextStatus() needs to be called to ensure that when we process the next rule, the "conjuctive contexts" are up to date before the next round of context change calculation. I do not want to change the behavior ofInstallPolicyRuleFlows
as it would cause regression issues.
Thanks for your PR. The following commands are available:
These commands can only be run by members of the vmware-tanzu organization. |
/test-all |
8f50c85
to
8df0b15
Compare
/test-all |
/test-conformance /test-networkpolicy /test-windows-networkpolicy |
Looks like the clusterAPI for Jenkins e2e builds are failing @lzhecheng
|
@Dyanngg Yes, this may relate to ip allocation. Could you try again? It should work now. |
This is an optimization for NetworkPolicy OVS flows to be collectively installed in agent restart case, so that those flows will rolled out at once and avoid potential priority re-assignments. In the future, mechanisms can also be added so that once this operation is done, NetworkPolicy flows from the previous round are deleted immediately after.
/test-all |
... as well as resolving comments
/test-all |
/test-windows-networkpolicy |
1 similar comment
/test-windows-networkpolicy |
Can one of the admins verify this patch? |
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 except two minor suggestions. If you apply the suggestions, feel free to merge once you get other reviewers' approval back.
/test-all |
/test-windows-conformance /test-windows-networkpolicy |
/test-windows-networkpolicy |
/test-windows-networkpolicy |
looks like flaky test result from windows np ..
merging as it is unrelated |
/cc @lzhecheng |
@abhiraut Thanks. There is something wrong on one testbed. I disconnected it and is investigating. |
Support for batch OVS flow updates This is an optimization for NetworkPolicy OVS flows to be collectively installed in agent restart case, so that those flows will rolled out at once and avoid potential priority re-assignments. In the future, mechanisms can also be added so that once this operation is done, NetworkPolicy flows from the previous round are deleted immediately after.
Currently in Antrea, OVS flows for NetworkPolicies are installed asynchronously. For agent restart cases however, the initial NetworkPolicy events before the Bookmark (#704) can be processed in batch and be sent to OVS bridge in a single bundle. This PR implements this methodology.