Bump network-policy-api dependency to v0.1.5

[Dyanngg]

Previously released version mistakenly contains go.mod dependency to
k8s.io/kubernetes, which should be removed.

In addition, there are following changes made in network-policy-api:

• sameLabels and notSameLabels are deprecated to make way for the
  future tenancy based API
• Peers are split into AdminNetworkPolicyIngress/EgressPeer since
  there will be a fqdn field added specifically for the egress peer
• Minor changes in terms of nesting of pod/ns selectors
• Conformance profiles are added

Antrea implementation has been updated to reflect those changes.

[antoninbas]

Just to clarify: you are intentionally keeping the /validate/anp and /validate/banp validation endpoints in the Antrea APIServer?

antrea/pkg/apiserver/apiserver.go

Lines 314 to 315 in 8a4682c

	s.Handler.NonGoRestfulMux.HandleFunc("/validate/anp", webhook.HandlerForValidateFunc(v.Validate))
	s.Handler.NonGoRestfulMux.HandleFunc("/validate/banp", webhook.HandlerForValidateFunc(v.Validate))

I think this is the right thing to do, as some users may be using an old Antrea YAML manifest with a newer Antrea container image. But maybe we should add a comment to apiserver.go to indicate why we have these paths registered, but we are not actually performing any validation?

BTW, the upstream API changes break backwards-compatibility, but I assume it was intentional (Alpha API)? Even then, it would have been nice to have an API version bump upstream (v1alpha2). I wonder if we should add a note in our own release notes for v2.1 about this breaking change. Not bumping up the API version upstream makes it difficult to track which "version" is implemented by a given version of a network plugin such as Antrea.

[antoninbas]

I'm curious to know what these 4 flags are for?

[Dyanngg]

So that we can generate a conformance report and put it upstream like https://github.com/kubernetes-sigs/network-policy-api/blob/main/conformance/reports/v0.1.2/ovn-kubernetes.yaml

[antoninbas]

How do you want to handle the version though? Because technically, the version being tested here is unreleased when this is run as part of CI.

What you could do if you want is use an environment variable, that can be set when calling this script, and would otherwise default to the contents of the VERSION file (which is at the root of the repository). Then you would add a new Github workflow that can be run on demand (workflow_dispatch trigger) and would run the tests for a specific released Antrea version (version string to be provided as a workflow input). The workflow would upload the generated compliance report as an artifact for convenient download, and could even be run automatically for new Antrea releases.
I think that's the right approach. but it could be done in a later PR. For now I would just recommend implementing part of this proposal:

• add VERSION environment variable or command-line flag
  • if provided, install the specified Antrea version and use the provided version value as -version
  • if not provided, keep the current behavior, but use the contents of the VERSION file ($(head -n1 $ROOT_DIR/VERSION)) for -version

[Dyanngg]

Will do. I'll update this PR once the network-policy-api cuts a v2.0 release, which is going to happen very soon

[antoninbas]

why did we have this function call before, given that this case was not supported?

[Dyanngg]

Yeah they shouldn't really be there, admission webhook would reject any policies that have these fields

[Dyanngg]

Just to clarify: you are intentionally keeping the /validate/anp and /validate/banp validation endpoints in the Antrea APIServer? I think this is the right thing to do, as some users may be using an old Antrea YAML manifest with a newer Antrea container image. But maybe we should add a comment to apiserver.go to indicate why we have these paths registered, but we are not actually performing any validation?

Yes I'll also add a TODO to have these removed at some point.

BTW, the upstream API changes break backwards-compatibility, but I assume it was intentional (Alpha API)? Even then, it would have been nice to have an API version bump upstream (v1alpha2). I wonder if we should add a note in our own release notes for v2.1 about this breaking change. Not bumping up the API version upstream makes it difficult to track which "version" is implemented by a given version of a network plugin such as Antrea.

Agreed

[github-actions]

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