On 1/23/26 10:39 AM, Rukomoinikova Aleksandra wrote: > On 22.01.2026 17:23, Dumitru Ceara wrote: >> On 1/22/26 2:04 PM, Rukomoinikova Aleksandra wrote: >>> On 21.01.2026 17:41, Dumitru Ceara wrote: >>>> Внимание: ВНЕШНИЙ отправитель! >>>> >>>> >>>> Будьте осторожны с вложениями и ссылками. >>>> >>>> >>>> On 12/19/25 10:48 AM, Alexandra Rukomoinikova wrote: >>>>> 1) Added tables for further implementation logic of service monitors for >>>>> logical switch ports: >>>>> >>>>> New table: >>>>> - Logical_Switch_Port_Health_Check: Health check configuration >>>>> for logical switch port. >>>>> >>>>> Modified tables: >>>>> - Logical_Switch_Port: Add 'health_checks' column referencing >>>>> health checks configuration. >>>>> >>>>> 2) Added commands to create, delete, and describe health checks for >>>>> logical switch ports. >>>>> >>>>> Signed-off-by: Alexandra Rukomoinikova <[email protected]> >>>>> --- >>>> Hi Alexandra, >>>> >>>> I started reviewing this series but before doing that I want to double >>>> check the use case. >>>> >>>> Is your plan to use these to check the availability of >>>> Logical_Switch_Ports as backends of NB.Load_Balancer? >>>> >>>> If so, how do you plan to add that mapping? I guess it would be a new >>>> feature in 26.09. >>>> >>>> Or is your goal to just expose the LSPHC.status to the CMS and then let >>>> the CMS update the list of backends of the LB? >>>> >>>> In any case we probably should: >>>> - update the documentation expanding on the use case more >>>> - update the commit log of this patch (and maybe the others too) >>>> - add a TODO.rst item for any follow up work we might be doing in 26.09. >>>> >>>> I have some more comments on the code changes themselves but I'll send >>>> those replies separately when I'm done going through the code. >>>> >>>> Thanks, >>>> Dumitru >>>> >>> Hi, we would like to use this functionality so that CMS can know about >>> the availability of the virtual machine, that is, yes, it is assumed >>> that the only client of this functionality is CMS - I can indicate this >>> in the documentation. Which option would you prefer? Could I correct >>> all your comments by tomorrow and have it included in the release, or >>> should I leave it all for 26.09 ? >>> >> Hi Alexandra, >> >> I think if it's properly documented that the CMS monitors the health >> check status the series still qualifies for 26.03. So we can try to >> include it there. >> >> In my review I didn't spot any huge blockers until now. >> >> Regards, >> Dumitru >> > > Hi Dumitru and Mark, >
Hi Alexandra, > I read comments you and Mark sent me, and I don't think we should > include this patch series in the release. I won't have time to properly > fix everything that needed fixing today, and I don't want to break > anything again or cut corners =) Thanks for the review, and I'm sorry > you had to waste time on this now, but I think it would be better if I > calmly improve everything. > Thanks for letting us know. I do want to make sure we're on the same page though. Soft freeze for 26.03 is scheduled for today. But that doesn't mean that all feature patches must be _merged_ before soft freeze. We have 4 more weeks (with soft freeze in effect) until we branch. In this period, patches for features that qualified for the release [0] can be worked on (posting new versions addressing comments) and may be merged: " 1. "Soft freeze" of the main branch. 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. " As your series has already been reviewed and no major blockers were raised, it means it _qualifies_ for 26.03.0. So you would have 4 more weeks to post new versions, receive review feedback on the new versions, address the feedback, get the patches merged into the main branch. At that point, after 4 weeks (scheduled for February 20th), we enter the "hard freeze" period, i.e., we will create branch-26.03 based on the main branch at that point, no new features are accepted on the new branch-26.03 anymore. Not even the ones that originally qualified for 26.03 but didn't get merged. New features may be merged on the main branch from this point on. Exceptions are possible though. So, TL/DR, you don't need to rush into sending a v2 now, in theory you have 4 weeks time. But the sooner the better of course. :) Regards, DUmitru [0] https://github.com/ovn-org/ovn/blob/2ddbb21ac699349c4a6122cd7bbef291a7d69ac2/Documentation/internals/release-process.rst#release-strategy > Thanks again! > >> > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
