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

fix(helpers) disable keyring in wait-for-db container #556

Merged
merged 3 commits into from
Mar 15, 2022

Conversation

fffonion
Copy link
Contributor

@fffonion fffonion commented Mar 9, 2022

What this PR does / why we need it:

The wait-for-db container checks for migration readiness. Since
it starts the full kong cluster, it also runs keyring bootstrap process:
the kong clster in that container generates the initial key,
store in its memory, and writes the key_id to keyring_meta table.
But it doesn’t have enough time to broadcast its key to other kong
container that serves proxy, admin, manager etc. By design,
keyring doesn't automatically generate a new key if there's
anything in the keyring_meta table, even no nodes have
knowledge to it; this it to avoid unnecessary rotation of keys.

This PR skips keyring bootstrap at wait-for-db container, so the
bootstrap can be done in an actual kong cluster.

Which issue this PR fixes

Special notes for your reviewer:

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

  • PR is based off the current tip of the main branch.
  • Changes are documented under the "Unreleased" header in CHANGELOG.md
  • New or modified sections of values.yaml are documented in the README.md
  • Commits follow the Kong commit message guidelines

@fffonion fffonion requested a review from a team as a code owner March 9, 2022 03:12
@CLAassistant
Copy link

CLAassistant commented Mar 9, 2022

CLA assistant check
All committers have signed the CLA.

@fffonion fffonion force-pushed the fix/keyring branch 4 times, most recently from edad552 to f877d13 Compare March 9, 2022 03:33
The wait-for-db container checks for migration readiness. Since
it starts the full kong cluster, it also runs keyring bootstrap process:
the kong clster in that container generates the initial key,
store in its memory, and writes the key_id to keyring_meta table.
But it doesn’t have enough time to broadcast its key to other kong
container that serves proxy, admin, manager etc. By design,
keyring doesn't automatically generate a new key if there's
anything in the keyring_meta table, even no nodes have
knowledge to it; this it to avoid unnecessary rotation of keys.

This PR skips keyring bootstrap at wait-for-db container, so the
bootstrap can be done in an actual kong cluster.
charts/kong/templates/_helpers.tpl Outdated Show resolved Hide resolved
charts/kong/templates/_helpers.tpl Outdated Show resolved Hide resolved
charts/kong/CHANGELOG.md Outdated Show resolved Hide resolved
fffonion and others added 2 commits March 15, 2022 20:04
Co-authored-by: Michał Flendrich <m.flendrich@gmail.com>
@fffonion
Copy link
Contributor Author

Thanks for the review @mflendrich, I have addressed the comments, could you take another look : )?

@rainest rainest merged commit 1a37f91 into Kong:main Mar 15, 2022
@fffonion fffonion deleted the fix/keyring branch March 16, 2022 17:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants