On Mon, Feb 9, 2026 at 9:44 AM Ales Musil <[email protected]> wrote: > > > > 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.
No objections from me either. Numan > >> >> >> 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
