Add antctl query for policy conjunction ID #6470
Conversation
The antctl query will be available in Antrea agents. It returns the OpenFlow conjunction ID(s) assigned for the queried policy's rules on that specific Node. Note that if a policy does not apply to any Pods on that Node, this antctl command will return a http NotFound since the Antrea agent will not have information of that policy. Signed-off-by: Dyanngg <dingyang@vmware.com>
Dyanngg
force-pushed
the
policy-conjunction
branch
from
de7bcc6
to
3a6ea9c
Compare
|
|
||
| // HandleFunc creates a http.HandlerFunc which uses an AgentNetworkPolicyInfoQuerier | ||
| // to query network policy rules in current agent. | ||
| func HandleFunc(aq agentquerier.AgentQuerier) http.HandlerFunc { |
There was a problem hiding this comment.
wouldn't it make sense to add this information (list of conj IDs) to the existing networkpolicy handler instead of defining a new HTTP endpoint? We can always enrich it if we need to support a few additional query parameters? Likewise, maybe we could use the existing antctl command and have a flag to display conjunction IDs?
There was a problem hiding this comment.
As of now the response type of the antctl get networkpolicy command is basically controlplane.NetworkPolicy since it's a shared endpoint between controller and agent. As a result it might be a bit tricky to add a conjunction ID field to the Response type, as for the controller it is this antctl command is a resourceEndpoint command https://github.com/antrea-io/antrea/blob/main/pkg/antctl/antctl.go#L227
There was a problem hiding this comment.
There are some differences already in the Agent command compared to the Controller command, and the handlers are different, but I think I see your point: we still use the same response type for both handlers, and it may not be a good idea to change that.
Is there any information that would be useful for debugging on the Agent-side besides conjunction IDs? I am wondering if we should have a more generic (but still Agent-specific) endpoint / command, not one named specifically "policyconjunctions". For example, would it make sense to also include the ruleID in the response, or anything else?
There was a problem hiding this comment.
Ummm if you are talking about the ID of the rule stored in agent, usually it does not carry information that we can use during debugging. It is a hash that's computed based on all fields of a rule and not really relatable to any controlplane rule info.
There was a problem hiding this comment.
I opened #6487 which fixed some old antctl ovs-dump command that would essentially show conjunction ID information (buried in the flows). However, it feels to me that it's still quite different from the command provided in this PR: the ovs-dump returns the datapath state, which, in times of troubleshooting, might return empty flows based on the match keys stored. Wondering if this PR is still warranted @tnqn
|
This PR is stale because it has been open 90 days with no activity. Remove stale label or comment, or this will be closed in 90 days |
github-actions
bot
added
the
lifecycle/stale
luolanzone
removed
the
lifecycle/stale
|
@Dyanngg can we include this to release 2.3? |
The antctl query will be available in Antrea agents. It returns the OpenFlow conjunction ID(s) assigned for the queried policy's rules on that specific Node.
Note that if a policy does not apply to any Pods on that Node, this antctl command will return a http NotFound since the Antrea agent will not have information of that policy.
In addition, this PR also corrects the deprecated ANP type flag in
antctl get networkpolicyqueries to point to the new AdminNetworkPolicy type.