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

Add Egress CRD types #1433

Merged
merged 1 commit into from
Apr 4, 2021
Merged

Add Egress CRD types #1433

merged 1 commit into from
Apr 4, 2021

Conversation

jianjuns
Copy link
Contributor

@jianjuns jianjuns commented Oct 23, 2020

Add types for egress policy CRDs, including Egress for the egress
policy definition, and a common AppliedTo struct for defining the scope
to which a policy is applied.

Issue: #667

@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).

@codecov-io
Copy link

codecov-io commented Oct 23, 2020

Codecov Report

Merging #1433 (082bbef) into main (e93ed12) will increase coverage by 1.20%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1433      +/-   ##
==========================================
+ Coverage   61.92%   63.13%   +1.20%     
==========================================
  Files         262      262              
  Lines       19473    19473              
==========================================
+ Hits        12059    12294     +235     
+ Misses       6167     5915     -252     
- Partials     1247     1264      +17     
Flag Coverage Δ
e2e-tests 25.40% <ø> (?)
kind-e2e-tests 53.34% <ø> (-0.05%) ⬇️
unit-tests 41.85% <ø> (-0.02%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
pkg/ipfix/ipfix_process.go 81.81% <0.00%> (-18.19%) ⬇️
pkg/agent/cniserver/pod_configuration.go 53.90% <0.00%> (-3.52%) ⬇️
pkg/controller/traceflow/controller.go 69.48% <0.00%> (-2.60%) ⬇️
pkg/agent/openflow/client.go 64.16% <0.00%> (+0.50%) ⬆️
pkg/agent/flowexporter/exporter/exporter.go 70.83% <0.00%> (+0.69%) ⬆️
...ntroller/networkpolicy/networkpolicy_controller.go 71.10% <0.00%> (+0.97%) ⬆️
pkg/agent/agent.go 48.92% <0.00%> (+1.19%) ⬆️
pkg/ovs/openflow/ofctrl_builder.go 57.89% <0.00%> (+1.31%) ⬆️
pkg/agent/flowexporter/connections/connections.go 81.67% <0.00%> (+1.52%) ⬆️
pkg/ovs/ovsconfig/ovs_client.go 51.73% <0.00%> (+1.62%) ⬆️
... and 13 more

// +genclient:noStatus
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object

type SNATPolicy struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this going to be a Namespaced scope CRD?

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 plan to start from cluster scoped.

Base automatically changed from master to main January 26, 2021 00:00
@jianjuns
Copy link
Contributor Author

jianjuns commented Mar 3, 2021

@tnqn : please let me know what you think about my new version?

@jianjuns jianjuns requested a review from tnqn March 3, 2021 07:09
@jianjuns jianjuns marked this pull request as ready for review March 3, 2021 19:17
Copy link
Member

@tnqn tnqn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess your command didn't finish successfully, there are 130 files are affected because of the year update.

// workloads in To/From fields. If set with PodSelector,
// Pods are matched from Namespaces matched by the NamespaceSelector.
// +optional
NamespaceSelector *metav1.LabelSelector `json:"namespaceSelector,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to this PR, I'm wondering if we could add a Namespace field to the EntitySelector which means selecting Pods in this namespace, just like how NetworkPolicyPeer in K8s NetworkPolicy works. Is this easier to use compared with "antrea.io/metadata.name" or "kubernetes.io/metadata.name" label?

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 think Abishek and Yang proposed the label way, because upstream NetworkPolicy decide to go that direction. @Dyanngg: please comment.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for bringing it up. In the upstream proposal, we're replacing the NamespaceSelector field with a new Namespaces field, which look like the following

type Namespaces struct {
	Self       bool
	Selector   *metav1.LabelSelector
	Except     []*metav1.LabelSelector
}

Namespaces.Selector will essentially replace NamespaceSelector. And user can easily write a Namespace isolation policy by setting Namespaces.Self=true. We are still on the fence about whether the Except field is necessary so I wouldn't put that in to start with (although there are quite some usecases which can be greatly simplified by except, like deny all traffic except from kube-system).
Link to the KEP: kubernetes/enhancements#2522

type EgressSpec struct {
// AppliedTo selects Pods to which the Egress will be applied.
// +optional
AppliedTo *antreacore.AppliedTo `json:"appliedTo,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be non pointer? It doesn't have a proper mean if it's nil, right?

Copy link
Contributor Author

@jianjuns jianjuns Mar 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In NetworkPolicy AppliedTo can be nil today, which means applied to all I think. Should we keep the behavior?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought over and now also feel empty AppliedTo probably makes more sense. Do you think so?

type AppliedTo struct {
// Selectors is the set of EntitySelectors that select entities.
// +optional
Selectors []EntitySelector `json:"selectors,omitempty"`
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Dyanngg, @tnqn, @antoninbas : do you see any reason to make it a slice? Today Antrea NetworkPolicy uses a slice of NetworkPolicyPeer so can be multiple Selectors too.

Copy link
Contributor Author

@jianjuns jianjuns Mar 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant I am thinking about:

type AppliedTo struct {
        PodSelector *metav1.LabelSelector
        NamespaceSelector *metav1.LabelSelector
        Groups []string
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to a single selector (pair) per inputs from Abhishek and Yang.

@jianjuns jianjuns force-pushed the egress-pol branch 2 times, most recently from be92580 to 3b3dbdd Compare March 4, 2021 22:01
@jianjuns
Copy link
Contributor Author

jianjuns commented Mar 4, 2021

I guess your command didn't finish successfully, there are 130 files are affected because of the year update.

Yes, noticed it, but there is no error returned by "make codegen".

I found out it is due to a previous failed run, which I commited to local. Fixed it.

Copy link
Member

@tnqn tnqn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jianjuns I tested this patch with controller code and it basically works. The only thing missing is the CRD manifest, do you plan to add it in this PR? or I could do it with another PR.

NamespaceSelector *metav1.LabelSelector `json:"namespaceSelector,omitempty"`
// Groups is the set of ClusterGroup names.
// +optional
Groups []string `json:"groups,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not consistent with Antrea NetworkPolicy where only a Group is allowed. It looks like multiple group will be supported by a nested group #1920.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. I think we should support multiple groups finally, but if we want to change NetworkPolicy together, I can switch to a single group for now.
@Dyanngg : thoughts?

Copy link
Contributor

@Dyanngg Dyanngg Mar 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think last time we discussed, the cardinality issue is not here in particular: the issue is that currently Antrea-native policies support multiple appliedTos, while @jianjuns suggests we only use a single core/v1alpha2.appliedTo for Antrea-native policies if we decide to share the appliedTo. So in upgrade case, there could be extra namespaceSelector and podSelector in the appliedTo list today that can not fit in the new spec. If we want to do some hacks (i.e. translating 1 old ACNP to multiple new ACNPs once appliedTo is unified), then I don't really have a preference here. If not, then maybe a list for Groups here would help, as we only need to put the groups mentioned in the old list of appliedTos in the slice there?

// +k8s:deepcopy-gen=package
// +groupName=egress.antrea.tanzu.vmware.com

package egress
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you plan to change to crd group after the renaming is done?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

@jianjuns
Copy link
Contributor Author

@jianjuns I tested this patch with controller code and it basically works. The only thing missing is the CRD manifest, do you plan to add it in this PR? or I could do it with another PR.

If we generate YAML then the CRDs are visible to users. I think we can publish YAML after the feature is complete. What you think?


// +genclient
// +genclient:noStatus
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// +genclient:nonNamespaced
@jianjuns the tag is needed to generate proper Lister, otherwise it will require a namespace to get an Egress.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed it.

@jianjuns jianjuns changed the title Add SNATPolicy CRD Add Egress CRD types Apr 2, 2021
tnqn
tnqn previously approved these changes Apr 2, 2021
Copy link
Member

@tnqn tnqn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@tnqn
Copy link
Member

tnqn commented Apr 2, 2021

/test-all

Add types for egress policy CRDs, including Egress for the egress
policy definition, and a common AppliedTo struct for defining the scope
to which a policy is applied.
Copy link
Member

@tnqn tnqn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@tnqn
Copy link
Member

tnqn commented Apr 3, 2021

/test-all

@jianjuns
Copy link
Contributor Author

jianjuns commented Apr 4, 2021

/test-e2e

@jianjuns jianjuns merged commit 4bc2316 into antrea-io:main Apr 4, 2021
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