When will v1beta2 be fixed? about multi-networkpolicy HOT 12 CLOSED

Currently we don't have any clear plan it yet. As usual Kubernetes API, we suppose different version might take incompatible changes because we alined with usual consensus.

from multi-networkpolicy.

we suppose different version might take incompatible changes because we alined with usual consensus.

Just want to clarify that, for the same version(v1beta2), when it's working version, does it take incompatible changes?

from multi-networkpolicy.

It depends on. Need to discuss in the community first.

from multi-networkpolicy.

@s1061123 the only change that has gone into v1beta2 is the support for endport. This will bring us close to NetworkPolicy feature wise.

So, can we please ratify v1beta2 and any other changes, if any, can come in subsequent versions of the API.

from multi-networkpolicy.

@girishmg Currently I don't have a time to proceed v1beta2 release. Appreciated if you could help that.

from multi-networkpolicy.

Absolutely, we would love to help.

Can you please let us know how to get involved? cc: @l8huang

from multi-networkpolicy.

Hi @l8huang and @girishmg

We don't have clear formalized process for that, so I just list up what I have. @dougbtv , could you please double check. Feel free to add.

1. Technical Requirements:

• Currently this API is used by several projects, so we cannot deprecate v1beta1. So please support both (v1beta1 and v1beta2) in this repo.
  • for example, as keep current scheme.yml and introduce another yaml file for v1beta2

2. Community Requirements:

• We have bi-weekly community meeting, so please attend that and discuss in the community. Meeting time is in the google doc and next meeting is 6/13.

https://docs.google.com/document/d/1oE93V3SgOGWJ4O1zeD1UmpeToa0ZiiO6LqRAmZBPFWM/edit

from multi-networkpolicy.

@l8huang can we please open this issue? As we are still discussing this and the path forward.

@s1061123 the existing customers can continue to use v1beta1 CR. When the new CR is applied with storage set to true for v1beta2, the K8s API server will just save that old v1beta1 CR has v1beta2 with endPort not set. Now, the OLD MNP controller, which understands only v1beta1, will ask K8s API server for v1beta1 objects for reconcilation. K8s API server will return v1beta1 object since it knows both the versions.

This is backwards compatible.

from multi-networkpolicy.

Currently this API is used by several projects, so we cannot deprecate v1beta1. So please support both (v1beta1 and v1beta2) in this repo.
for example, as keep current scheme.yml and introduce another yaml file for v1beta2

Having multiple scheme.ymls could make things complicated, Istio API and k8s/gateway-api uses same same definitions for all versions, all versions are served and only one version has storage: true.

If multi-network policies adopt the same practice, the endPort field should be added into both v1beta1 and v1beta2. The distinctions between the fixed and working versions are conceptual; essentially, they are identical.

Reference: Istio CRD Versioning

from multi-networkpolicy.

If multi-network policies adopt the same practice, the endPort field should be added into both v1beta1 and v1beta2. The distinctions between the fixed and working versions are conceptual; essentially, they are identical.

If we should, v1beta1 and v1beta2 is pretty same, so we don't have v1beta2, right? In such case, we don't require v1beta2 no longer, to support endPort. So how about to just add endPort to v1beta1?

As you know, endPort is optional, so v1beta1 could add endPort without any conversion, I suppose.

from multi-networkpolicy.

If multi-network policies adopt the same practice, the endPort field should be added into both v1beta1 and v1beta2.

What is the meaning of versioning then? It doesn't make sense to me atleast.

from multi-networkpolicy.

TL;DR:

• gateway-api v1 and v1betaN have same definition
• versioning is done at the API level -- k8s gateway-api uses <gateway:experimental> to define experimental fields, istio just simplifies versioning by making all versions(v1, beta, alpha) same
• The promotion of a CRD follows a progression from alpha to beta and v1, rather than incrementing through versions such as v1beta1, v1beta2, v1beta3, and so forth

gateway-api follows The Kubernetes API, the Alpha, Beta, and Stable Versions represent the API's maturity level, and versioning is done at the API level

API groups and versioning

Versioning is done at the API level rather than at the resource or field level to ensure that the API presents a clear, consistent view of system resources and behavior, and to enable controlling access to end-of-life and/or experimental APIs.
API resources are distinguished by their API group, resource type, namespace (for namespaced resources), and name. The API server handles the conversion between API versions transparently: all the different versions are actually representations of the same persisted data. The API server may serve the same underlying data through multiple API versions.

For example, suppose there are two API versions, v1 and v1beta1, for the same resource. If you originally created an object using the v1beta1 version of its API, you can later read, update, or delete that object using either the v1beta1 or the v1 API version, until the v1beta1 version is deprecated and removed. At that point you can continue accessing and modifying the object using the v1 API.

An gateway-api API is promoted from Alpha to Beta and Stable, e.g. Gateway is gateway.networking.k8s.io/v1, its CRD has same schema for v1 and v1beta1; TCPRoute is gateway.networking.k8s.io/v1alpha2, its CRD only has version v1alpha2, v1alpha2 CRD are in experimental folder.

gateway-api has a way to define an experimental field in v1/v1beta1 API, e.g Gateway field Infrastructure:

	// Infrastructure defines infrastructure level attributes about this Gateway instance.
	//
	// Support: Core
	//
	// <gateway:experimental>
	// +optional
	Infrastructure *GatewayInfrastructure `json:"infrastructure,omitempty"`

it appears in crd/experimental/gateway.networking.k8s.io_gateways.yaml's v1 and v1beta1, but not in crd/standard/gateway.networking.k8s.io_gateways.yaml

from multi-networkpolicy.