Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add antctl query for policy conjunction ID #6470
base: main
Are you sure you want to change the base?
Add antctl query for policy conjunction ID #6470
Changes from all commits
3a6ea9c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As of now the response type of the
antctl get networkpolicy
command is basicallycontrolplane.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 aresourceEndpoint
command https://github.com/antrea-io/antrea/blob/main/pkg/antctl/antctl.go#L227There 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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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