On 1/26/26 1:22 PM, Dumitru Ceara wrote: > Hi everyone, > > Since Friday, January 23rd, OVN is effectively in the "soft freeze" > state in preparation for the branching and release of OVN 26.03.0. > As per Documentation/internals/release-process.rst, this means: > > During the freeze, we ask committers to refrain from applying patches that > add new features unless those patches were already posted for public review > and had received public review feedback on the mailing list before the > freeze began. Bug fixes are welcome at any time. Please propose and > discuss exceptions on ovs-dev. > > The 26.03 branch is scheduled to be created in ~4 weeks from now, > on Friday, February 20th and the release should be another 4 weeks > later, on Friday, March 20th. > > There are currently, on the mailing list (and in patchwork), quite > a few patch sets that have already been discussed and reviewed to > some reasonable extent (for some of them changes have been > requested). All these, of course, qualify for potential > acceptance in 26.03.0. > > If there are new patches that never been reviewed or have not been > posted yet, please propose an exception in reply to this email and > we can discuss further. > > In my opinion, one not-yet-posted series that should be treated > as an exception, is the follow up work requested for [0]: > > "[ovs-dev] ovn-nb, ovn-nbctl: Add ID column to Network_Function table." > which implies that a significant change needs to happen inside > the implementation of the Network Function feature - this change > has only informally been discussed on-list, the patch is yet to > be posted. However, in order to avoid upgrade issues post 26.03 > it's preferable if we include this work in the current release. >
I know it's a bit late but I'd like to discuss one more thing: OVN's EVPN support is marked as experimental but based on discussions with potential users we're quite confident it's usable in its current form. So I'm planning to prepare a patch that removes its "experimental" designation in 26.03. I assume that's OK. But, before I do that I'd also like to remove the default "dynamic-routing-*-ifname" values. OVN assumes that if the user didn't configure the vxlan/bridge/lo interface names explicitly for a given EVPN enabled logical switch then they exist on the host with the names "br-$vni", "vxlan-$vni", "lo-$vni". This doesn't play well with dual-stack scenarios where we'd also need a "vxlan-v6-$vni" (or similar) interface. I'm actually thinking now that it makes no sense to assume this naming scheme and it's probably better if the CMS just configures explicit names. So I'd also like to work and post a patch that removes this part of the feature (the implied default interface names) as it's not really useful. As that might be a bit against our soft freeze rules, I'd like to request an exception keeping in mind, again, that this is an experimental feature and that we're not really changing any of the behavior, just removing (unfortunate) defaults. Regards, Dumitru > Regards, > Dumitru > > [0] > https://patchwork.ozlabs.org/project/ovn/patch/[email protected]/ _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
