Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

Dyanngg
Copy link
Contributor

@Dyanngg Dyanngg commented Aug 7, 2020

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.

@antrea-bot
Copy link
Collaborator

Thanks for your PR.
Unit tests and code linters are run automatically every time the PR is updated.
E2e, conformance and network policy tests can only be triggered by a member of the vmware-tanzu organization. Regular contributors to the project should join the org.

The following commands are available:

  • /test-e2e: to trigger e2e tests.
  • /skip-e2e: to skip e2e tests.
  • /test-conformance: to trigger conformance tests.
  • /skip-conformance: to skip conformance tests.
  • /test-whole-conformance: to trigger all conformance tests on linux.
  • /skip-whole-conformance: to skip all conformance tests on linux.
  • /test-networkpolicy: to trigger networkpolicy tests.
  • /skip-networkpolicy: to skip networkpolicy tests.
  • /test-windows-conformance: to trigger windows conformance tests.
  • /skip-windows-conformance: to skip windows conformance tests.
  • /test-windows-networkpolicy: to trigger windows networkpolicy tests.
  • /skip-windows-networkpolicy: to skip windows networkpolicy tests.
  • /test-hw-offload: to trigger ovs hardware offload test.
  • /skip-hw-offload: to skip ovs hardware offload test.
  • /test-all: to trigger all tests (except whole conformance).
  • /skip-all: to skip all tests (except whole conformance).

These commands can only be run by members of the vmware-tanzu organization.

@Dyanngg Dyanngg changed the title Agent supports ExternalEntity. [ANP] ExternalEntity support for agent Aug 7, 2020
@Dyanngg Dyanngg requested review from tnqn, abhiraut, jianjuns and suwang48404 and removed request for tnqn August 7, 2020 23:40
Copy link
Contributor

@antoninbas antoninbas left a 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

pkg/agent/controller/networkpolicy/cache.go Outdated Show resolved Hide resolved
pkg/agent/controller/networkpolicy/cache.go Outdated Show resolved Hide resolved
@suwang48404
Copy link
Contributor

@abhiraut @tnqn @jianjuns can u guys please help review

Thx

@Dyanngg Dyanngg force-pushed the agent-ee branch 2 times, most recently from cb2e24e to 58468f4 Compare August 10, 2020 21:46
@antrea-bot
Copy link
Collaborator

Thanks for your PR.
Unit tests and code linters are run automatically every time the PR is updated.
E2e, conformance and network policy tests can only be triggered by a member of the vmware-tanzu organization. Regular contributors to the project should join the org.

The following commands are available:

  • /test-e2e: to trigger e2e tests.
  • /skip-e2e: to skip e2e tests.
  • /test-conformance: to trigger conformance tests.
  • /skip-conformance: to skip conformance tests.
  • /test-whole-conformance: to trigger all conformance tests on linux.
  • /skip-whole-conformance: to skip all conformance tests on linux.
  • /test-networkpolicy: to trigger networkpolicy tests.
  • /skip-networkpolicy: to skip networkpolicy tests.
  • /test-windows-conformance: to trigger windows conformance tests.
  • /skip-windows-conformance: to skip windows conformance tests.
  • /test-windows-networkpolicy: to trigger windows networkpolicy tests.
  • /skip-windows-networkpolicy: to skip windows networkpolicy tests.
  • /test-hw-offload: to trigger ovs hardware offload test.
  • /skip-hw-offload: to skip ovs hardware offload test.
  • /test-all: to trigger all tests (except whole conformance).
  • /skip-all: to skip all tests (except whole conformance).

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.
@suwang48404
Copy link
Contributor

Hi @abhiraut @tnqn @jianjuns,

ping ?

@@ -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 {
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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?)?

Copy link
Contributor

@suwang48404 suwang48404 Aug 11, 2020

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.

Copy link
Contributor

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.

Copy link
Contributor

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

  1. controller will not forward the AppliedToGroup (contain externalEntity) to agent
  2. even if controller (via bug) forward AppliedToGroup( contain externalEntity) to agent, agent ignores externalEntity in AppliedToGroup.

I hope this satisfies ur requirements.

Copy link
Contributor

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.

Copy link
Contributor

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.

@Dyanngg
Copy link
Contributor Author

Dyanngg commented Aug 26, 2020

Superseded by #1084

@Dyanngg Dyanngg closed this Aug 26, 2020
@Dyanngg Dyanngg deleted the agent-ee branch September 30, 2020 23:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants