On Mon, Feb 9, 2026 at 12:13 PM Dumitru Ceara <[email protected]> wrote:
> 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. > > > Hi Dumitru, thank you for raising this up. > > 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. > Obviously I'm biased, but no objections from my side. > > Regards, > Dumitru > > > Regards, > > Dumitru > > > > [0] > https://patchwork.ozlabs.org/project/ovn/patch/[email protected]/ > > Regards, Ales _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
