Comments (12)
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.
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.
- 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
- 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.yml
s 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.
Related Issues (11)
- Add unit-tests
- Docker support HOT 1
- Add scoping (limit to apply the policy) with net-attach-def
- MatchExpressions support
- Change repo name to generic name (not only macvlan) HOT 1
- Cleanup iptables when controller exits
- Reflector cannot access NetworkPolicies since v1beta1 change HOT 3
- Create multi-networkpolicy-iptables (or something like that) to keep API only in this repository HOT 4
- Support for `endPort` in multi-networkpolicy HOT 4
- SharedInformerFactory missing a Shutdown method HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from multi-networkpolicy.