| Message ID | 20221122092933.291120-1-amusil@redhat.com |
|---|---|
| Headers | show |
| Series | Allow related traffic for LB | expand |
On 11/22/22 10:29, 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. > --- I pushed this version to the main branch. However, it's still not 100% clear to me if there are other upgrade related issues we should address on top of it. Frode, does this change, which introduces and uses a new action unconditionally in ovn-northd, affect upgrade scenarios in your deployments? Upgrading ovn-controllers first and then central components should work fine. Upgrading in any order with ovn-match-northd-version set on all chassis should also not disrupt existing flows. As a final fail safe we could also backport the feature flag bits that Ales added in v5 [0]. But I'd prefer not doing that if not really needed. Looking forward to your feedback! Thanks, Dumitru [0] https://patchwork.ozlabs.org/project/ovn/patch/20221122150315.719739-3-amusil@redhat.com/
On Mon, Nov 28, 2022 at 5:17 PM Dumitru Ceara <dceara@redhat.com> wrote: > > On 11/22/22 10:29, 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. > > --- > > I pushed this version to the main branch. > > However, it's still not 100% clear to me if there are other upgrade > related issues we should address on top of it. > > Frode, does this change, which introduces and uses a new action > unconditionally in ovn-northd, affect upgrade scenarios in your deployments? > > Upgrading ovn-controllers first and then central components should work > fine. > > Upgrading in any order with ovn-match-northd-version set on all chassis > should also not disrupt existing flows. > > As a final fail safe we could also backport the feature flag bits that > Ales added in v5 [0]. But I'd prefer not doing that if not really needed. > > Looking forward to your feedback! Thank you for reaching out to me on this topic, Dumitru! I don't see any immediate issues with this, and agree that it is better to avoid the feature flag when not needed.
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. Ales Musil (2): actions: Add new action called ct_commit_nat northd: Allow related traffic through LB include/ovn/actions.h | 3 + lib/actions.c | 42 +++++++- northd/northd.c | 29 ++++-- northd/ovn-northd.8.xml | 29 ++++-- ovn-sb.xml | 12 +++ tests/ovn-northd.at | 210 +++++++++++++++++++++------------------- tests/ovn.at | 15 ++- tests/system-ovn.at | 135 ++++++++++++++++++++++++++ utilities/ovn-trace.c | 34 +++++++ 9 files changed, 387 insertions(+), 122 deletions(-)