Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(clustering): an optimization for the compatibility of CP and DP #12778

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

liverpool8056
Copy link
Contributor

@liverpool8056 liverpool8056 commented Mar 25, 2024

Summary

Background:

Kong ensures the backward compatibility through the logic of remove_fields that CP with higher verion can removes fields which are not supported by DPs in lower version before sending the configuration to DPs.

In detail, CP checks the version reporting by DP. If the version from DP is less than the version defined in remove_fields, the fields will be removed. So the logic is just a simple comparison.

Issue:

This logic works well for most of the cases. However, after serval backports to various version series, the comparsion should become more complex as there would be several incontinous ranges where the fields should be removed due to multiple backports.

Solution:

In this PR, a lower bound is added to the comparison when necessary rather than only a upper bound previously.

The new logic is that the comparison should punch through the range of the minor version for the earliest version since the field is supported, otherwise, the comparsion should be limited with the range of minor version.

Example

Let say a new field is initially introduced since 3.7.7. At this monent, an entry defined in removed_fields.lua should be:


-- Any dataplane older than 3.7.7
[3007007000] = {
    some_plugin = {
      "new_field",
    },
  },

And then it is backported into 3.5.5, 3.6.6. After that, the ranges where it's going to be removed or not turns into the followings:

  • (-infinite, 3.5.5 ), remove
  • [ 3.5.5, 3.6.0 ), don't remove
  • [ 3.6.0, 3.6.6 ), remove
  • [ 3.6.6, 3.7.0 ), don't remove
  • [ 3.7.0, 3.7.7 ), remove
  • [ 3.7.7, +infinite), don't remove

At this monent, in terms of the new logic, the removed_fields.lua should be:


-- Any dataplane older than 3.5.5
[3005005000] = {
  some_plugin = {
    "new_field",
  },
},

-- Any dataplane older than 3.6.6
[3006006000] = {
  some_plugin = {
    "new_field",
  },
},

-- Any dataplane older than 3.7.7
[3007007000] = {
  some_plugin = {
    "new_field",
  },
},

The comparsion should be dp_version < 3005005000 for the first entry as it is the earliest version it is supported and it should punch through the minor version.

The other two comparsions should be:
dp_version < 3006006000 and dp_version >= 3006000000 and dp_version < 3007007000 and dp_version >= 3007000000 respectively as it is not the earliest version it is supported and the comparison should be limited within the minor version.

With the help of this change, the removed_fields.lua can be consistent across version series, and we can easily append a new entry correspondingly when there is a backport.

Checklist

  • The Pull Request has tests
  • A changelog file has been created under changelog/unreleased/kong or skip-changelog label added on PR if changelog is unnecessary. README.md
  • There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Issue reference

Fix #[issue number]

Kong ensures the backward compatibility through the logic of `remove_fields`
that CP with higher verion can removes fields which are not supported
by DPs in lower version before sending the configuration to DPs.

In detail, CP checks the version reporting by DP. If the version from DP
is less than the version defined in `remove_fields`, the fields will be
removed. So the logic is just a simple comparison.

**Issue:**

This logic works well for most of the cases. However, after serval
backports to various version series, the comparsion should become more
complex as there would be several incontinous ranges where the fields
should be removed due to multiple backports.

**Solution:**

In this PR, a lower bound is added to the comparison when necessary
rather than only a upper bound previously.

The new logic is that the comparison should punch through the range of
the minor version for the earliest version since the field is supported,
otherwise, the comparsion should be limited with the range of minor version.

**Example**

Let say a new field is initially introduced since 3.7.7. At this monent,
an entry defined in `removed_fields.lua` should be:

```

-- Any dataplane older than 3.7.7
[3007007000] = {
    some_plugin = {
      "new_field",
    },
  },

```

And then it is backported into 3.5.5, 3.6.6. After that, the ranges
where it's going to be removed or not turns into the followings:

- (-infinite,  3.5.5 ), remove
- [  3.5.5,    3.6.0 ), don't remove
- [  3.6.0,    3.6.6 ), remove
- [  3.6.6,    3.7.0 ), don't remove
- [  3.7.0,    3.7.7 ), remove
- [  3.7.7, +infinite), don't remove

At this monent, in terms of the new logic, the `removed_fields.lua`
should be:

```

-- Any dataplane older than 3.5.5
[3005005000] = {
  some_plugin = {
    "new_field",
  },
},

-- Any dataplane older than 3.6.6
[3006006000] = {
  some_plugin = {
    "new_field",
  },
},

-- Any dataplane older than 3.7.7
[3007007000] = {
  some_plugin = {
    "new_field",
  },
},

```

The comparsion should be `dp_version < 3005005000` for the first
entry as it is the earliest version it is supported and it should punch
through the minor version.

The other two comparsions should be:
`dp_version < 3006006000 and dp_version >= 3006000000` and
`dp_version < 3007007000 and dp_version >= 3007000000` respectively as
it is not the earliest version it is supported and the comparison should
be limited within the minor version.

With the help of this change, the `removed_fields.lua` can be
consistent across version series, and we can easily append a new
entry correspondingly when there is a backport.
@github-actions github-actions bot added core/clustering cherry-pick kong-ee schedule this PR for cherry-picking to kong/kong-ee labels Mar 25, 2024
@chronolaw chronolaw changed the title An optimization for the compatibility of CP and DP refactor(clustering): an optimization for the compatibility of CP and DP Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cherry-pick kong-ee schedule this PR for cherry-picking to kong/kong-ee core/clustering size/L skip-changelog
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant