On 2/25/25 5:26 PM, Ilya Maximets wrote: > On 2/6/25 19:44, Mark Michelson wrote: >> On 2/6/25 08:42, Ilya Maximets wrote: >>> On 2/2/25 20:14, Lorenzo Bianconi wrote: >>>> Introduce ipv6_src and ipv6_dst to selection_fields column in >>>> Load_Balancer Logical_Router_Static_Route tables in order to properly >>>> load-balance IPv6 traffic if these fields are selected in group hash >>>> algorithm. >>>> >>>> Reported-at: https://issues.redhat.com/browse/FDP-1032 >>>> Signed-off-by: Lorenzo Bianconi <lorenzo.bianc...@redhat.com> >>>> --- >>>> Changes in v4: >>>> - improve test case >>>> - fix documentation and comments >>>> Changes in v3: >>>> - improve documentation >>>> - improve self-tests >>>> Changes in v2: >>>> - add new load-balancer Dual stack system test >>>> --- >>>> ovn-nb.ovsschema | 9 +- >>>> ovn-nb.xml | 10 +- >>>> tests/ovn.at | 6 +- >>>> tests/system-ovn.at | 256 +++++++++++++++++++++++++++++++++++++++++++- >>>> 4 files changed, 269 insertions(+), 12 deletions(-) >>> >>> Thanks, Lorenzo, for v4! This change and the test look fnctionally >>> correct to me. I left a few small, mostly styling, comments below. >>> Not sure if maintainers will want to address those on commit, but >>> with them addressed: >>> >>> Acked-by: Ilya Maximets <i.maxim...@ovn.org> >> >> I made the suggested changes and pushed this to main. > > Hi, Mark, Lorenzo, others. >
Hi Ilya, +more maintainers for opinions on backporting this. > Looking at how the original code is written, it assumed that the selection > fields work for IPv6 traffic as well. There was even a test case checking > IPv6 load balancing, though incorrectly. Taking that into account, I think, > this one should be treated as a bug fix and be backported. There are also > existing users like ovn-kubernetes that assumed that IPv6 load balancing > works. > This sounds reasonable to me. > Backporting schema changes is a bit tricky, sure, but can be done if the > schema versions are carefully chosen to not overlap with any existing ones > while staying lower than the versions from newer branches. > IMO that's probably fine but.. Should we try to document this somehow? While at it, our documentation is vague (or I might be interpreting it wrong). "Fail safe" upgrades seem well defined (always go to the most recent dot-release on the branch you're currently on and then upgrade to the most recent release of the branch you're moving to) but "rolling upgrades" don't seem to be well specified: " The following rolling upgrade paths are supported: 1. LTS to the very next LTS release, or to any non-LTS in between the two. 2. Any non-LTS to the very next LTS release. " https://github.com/ovn-org/ovn/blob/main/Documentation/intro/install/ovn-upgrades.rst#rolling-upgrade Should we make it clear that in the rolling upgrade case we should also upgrade to the most recent release of the branch we're upgrading to? > What do you think? > > Best regards, Ilya Maximets. > Regards, Dumitru _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
