On 11/25/22 16:40, Numan Siddique wrote: > On Fri, Nov 25, 2022 at 4:53 AM Dumitru Ceara <[email protected]> wrote: >> >> On 11/22/22 16:03, Ales Musil wrote: >>> The related traffic wasn't correctly forwarded >>> through the LB, the main issue was that the >>> traffic was not NATted. This series allows >>> the NAT to be applied and the traffic should >>> arrive with correct addresses. >>> --- >>> v2: Add e2e test case. >>> v3: Rebase on top of main. >>> Address comments from Mark. >>> v4: Rebase on top of main. >>> v5: Add feature flag for backward compatibility. >> >> As discussed offline, we don't expect to backport this feature. So v4 >> should be reviewed instead. >> > > Even if we are not backporting, shouldn't having the feature flag help > in upgrade scenarios ? > Particularly when CMS upgrades OVN central components first ? >
My understanding was that we should support the following types of upgrades: a. to a new major ovn version (e.g., x.y.z -> x.(y+1).z): we only support upgrading ovn-controllers first and then the central components. b. to a new minor version (e.g., x.y.z -> x.y.(z+1)): we support both orders of upgrades. For example, we needed to add a feature flag when we backported the use of ct_lb_mark: https://mail.openvswitch.org/pipermail/ovs-dev/2022-June/394517.html But we didn't have to do that when adding other features/actions that weren't backported; e.g., ecmp_symmetric_reply next-hop timeouts: https://mail.openvswitch.org/pipermail/ovs-dev/2022-July/396292.html > Just thinking out loud to avoid any upgrade issues in the future. > > Numan > I would prefer if we could avoid feature flags. Han had other concerns about feature flags (e.g., misbehaving chassis disabling a feature). Regards, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
