Open tssurya opened 1 month ago
Describe the issue:
We added support for networks peer which is a list of inline CIDRs https://github.com/kubernetes-sigs/network-policy-api/pull/185
networks
There are currently two implementations definitely who have implemented this:
Other CNI implementations like Kube-OVN are waiting for this API to be in standard channel rather than experimental: https://github.com/kubeovn/kube-ovn/issues/3247#issuecomment-2434366673
are there any concerns from the maintainers of the repo if I move this peer to standard channel?
@danwinship / @Dyanngg / @aojea / @astoycos ?
As per our docs: https://network-policy-api.sigs.k8s.io/versioning/?h=beta#experimental-standard (I can open another issue to track what we spoke about whether we want standard/experimental to mean stability OR optional but for all intents and purposes of this field there was no controversies on the optional/mandatory bits so we should try to focus on stability aspects here); it seems I need to fullfill alpha->beta chain of events: https://network-policy-api.sigs.k8s.io/versioning/?h=beta#alpha-beta
so we seems to satisfy most of the requirements here. Only missing bit is validation which I was waiting for 1.31 kube to have isCIDR validation: https://github.com/kubernetes-sigs/network-policy-api/pull/256/files#diff-e14a317f3c12a983e1037dec16d99833bd1398ab66a65a8b6476adad81d05b1cR150 so once we fix the bump to 1.31 we should be able to move networks peer.
/assign @tssurya
I will also tag all active community members for awareness @npinaeva @fasaxc @nathanjsweet
Networks is the new IPBlocks, right?
yup! https://network-policy-api.sigs.k8s.io/npeps/npep-126-egress-traffic-control/#implementing-egress-traffic-control-towards-cidrs
Describe the issue:
We added support for
networks
peer which is a list of inline CIDRs https://github.com/kubernetes-sigs/network-policy-api/pull/185There are currently two implementations definitely who have implemented this:
Other CNI implementations like Kube-OVN are waiting for this API to be in standard channel rather than experimental: https://github.com/kubeovn/kube-ovn/issues/3247#issuecomment-2434366673
are there any concerns from the maintainers of the repo if I move this peer to standard channel?
@danwinship / @Dyanngg / @aojea / @astoycos ?
As per our docs: https://network-policy-api.sigs.k8s.io/versioning/?h=beta#experimental-standard (I can open another issue to track what we spoke about whether we want standard/experimental to mean stability OR optional but for all intents and purposes of this field there was no controversies on the optional/mandatory bits so we should try to focus on stability aspects here); it seems I need to fullfill alpha->beta chain of events: https://network-policy-api.sigs.k8s.io/versioning/?h=beta#alpha-beta
so we seems to satisfy most of the requirements here. Only missing bit is validation which I was waiting for 1.31 kube to have isCIDR validation: https://github.com/kubernetes-sigs/network-policy-api/pull/256/files#diff-e14a317f3c12a983e1037dec16d99833bd1398ab66a65a8b6476adad81d05b1cR150 so once we fix the bump to 1.31 we should be able to move networks peer.