-
Notifications
You must be signed in to change notification settings - Fork 367
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
[ANP] ExternalEntity support for agent #1056
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.
LGTM, but someone else should review
cb2e24e
to
58468f4
Compare
Thanks for your PR. The following commands are available:
|
This commit moves ToAddresses/FromAddresses in CompletedRule and AddressSetByGroup in ruleCache to use GroupMemberSet instead of GroupMmeberPodSet. Thus both Pods and ExternalEntities are expressed as GroupMember when in these fields. Pods in appliedTo field continue be expressed by existing GroupMemberPod, and migration to GroupMember shall be done in a subsequent PR.
@@ -417,16 +432,23 @@ func (c *ruleCache) PatchAddressGroup(patch *v1beta1.AddressGroupPatch) error { | |||
c.addressSetLock.Lock() | |||
defer c.addressSetLock.Unlock() | |||
|
|||
podSet, exists := c.addressSetByGroup[patch.Name] | |||
groupMemberSet, exists := c.addressSetByGroup[patch.Name] | |||
if !exists { | |||
return fmt.Errorf("AddressGroup %v doesn't exist in cache, can't be patched", patch.Name) | |||
} | |||
for i := range patch.AddedPods { |
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.
Question - we still keep AddedPods/RemovedPods, after add AddedGroupMembers/RemovedGroupMembers?
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.
The plan is to deprecate GroupMemberPod and GroupMemberPodSet in the future, so those funcs will be unified.
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.
But as of now when controller will send AddedPods/RemovedPod, when AddedGroupMembers/RemovedGroupMembers?
// Source GroupMembers of this rule, can't coexist with ToAddresses. | ||
FromAddresses v1beta1.GroupMemberSet | ||
// Destination GroupMembers of this rule, can't coexist with FromAddresses. | ||
ToAddresses v1beta1.GroupMemberSet | ||
// Target Pods of this rule. | ||
Pods v1beta1.GroupMemberPodSet |
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.
Why target cannot be external endpoints?
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 believe the reason is that for the externalEntities in the appliedTo, there's nothing to be enforced from the Antrea agent side. The antrea-cloud controller will enforce firewall rules on the cloud provider instead.
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.
Ok. I thought we will support agented model together.
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.
would let @suwang48404 comment on that
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.
If we do not support agented model for external Nodes, then we need not any code in agent to handle ExternalEndpoints/Nodes (I think you still have such code?)?
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.
yes.
use case is that use ANP to control Pods' access to services on cloud (VMs or cloud Native Services). This was part of antrea+ demo.
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.
Ok. Then for Antrea perspective, it is more about supporting externalEntity in from/to. Still do not feel it is very useful alone. If am ok to make it the first step, but we should either have a way to validate externalEntity cannot be in appliedTo, or have a featureGate to disable the whole externalEntity support?
Let us talk offline.
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.
Hi @jianjuns
@Dyanngg has kindly taking over antrea externalEntity support. If u have any concrete suggestions, he will help out.
Regarding to ur suggestion about " ... either have a way to validate externalEntity cannot be in appliedTo, or ...", if I recall correctly, if user specifies ExternalEntity in appliedTo field of an ANP
- controller will not forward the AppliedToGroup (contain externalEntity) to agent
- even if controller (via bug) forward AppliedToGroup( contain externalEntity) to agent, agent ignores externalEntity in AppliedToGroup.
I hope this satisfies ur requirements.
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 would say it is very confusing to users. We should document we do not support appliedTo and validate it, or disable the externalEntity feature until we really support agent on external Nodes.
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 was chatting with @abhiraut on this. We also feel namespaced externalEntity does not make much sense from Antrea perspective. But anyway we might start from what we have now, but at least we should add some validation no externalEntity in appliedTo.
Superseded by #1084 |
This PR is rebased from and replaces #782.
It moves ToAddresses/FromAddresses in CompletedRule and AddressSetByGroup in ruleCache to use GroupMemberSet instead of GroupMmeberPodSet. Thus both Pods and ExternalEntities are expressed as GroupMember when in these fields.
Pods in appliedTo field continue be expressed by existing GroupMemberPod, and migration to GroupMember shall
be done in a subsequent PR.