This repository has been archived by the owner on Feb 22, 2022. It is now read-only.
[stable/kong] run migration when Kong is updated via Helm #9047
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
helm-bot
added
Contribution Allowed
k8s-ci-robot
added
the
approved
|
ping @shashiranjan84 |
Whenever Kong is updated using Helm, we need to ensure that migrations are run. For this purpose, a change has been made to run migrations using a pre-upgrade hook. The migration Job is being duplicated to avoid a cyclic dependency that arises with use of pre-install or post-install hooks as detailed below: Background: Kong uses a database to store configuration. The migrations for the database need to be run initially when Kong is installed and then on every upgrade. The pre-upgrade hooks solves the problem of running migrations on every upgrade. However, to run migrations during an installation has some challanges: - `pre-install` hook doesn't work in our case because, postgres deployment is not available in that phase. This means that the migration will never succeed and the deployment will always fail. - `post-install` hook introduces a cyclic dependency on the Kong container to start. `post-install` hook is executed only after all the deployments are in ready state. But the Kong deployment will not be ready till the migrations are run and migrations won't run till Kong deployment is ready. To overcome this, we are going to use two Jobs. One, which is executed when the Kong is initially installed and then the another one, which is used on every upgrade. Signed-off-by: Harry Bagdi <harrybagdi@gmail.com>
hbagdi
force-pushed
the
kong/migrations-on-upgrade
branch
from
a19d149
to
5c2efdb
Compare
helm-bot
added
size/M
|
/lgtm |
|
@hbagdi: you cannot LGTM your own PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hbagdi, shashiranjan84 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
3 tasks
wgiddens
pushed a commit
to wgiddens/charts
that referenced
this pull request
Jan 18, 2019
Whenever Kong is updated using Helm, we need to ensure that migrations are run. For this purpose, a change has been made to run migrations using a pre-upgrade hook. The migration Job is being duplicated to avoid a cyclic dependency that arises with use of pre-install or post-install hooks as detailed below: Background: Kong uses a database to store configuration. The migrations for the database need to be run initially when Kong is installed and then on every upgrade. The pre-upgrade hooks solves the problem of running migrations on every upgrade. However, to run migrations during an installation has some challanges: - `pre-install` hook doesn't work in our case because, postgres deployment is not available in that phase. This means that the migration will never succeed and the deployment will always fail. - `post-install` hook introduces a cyclic dependency on the Kong container to start. `post-install` hook is executed only after all the deployments are in ready state. But the Kong deployment will not be ready till the migrations are run and migrations won't run till Kong deployment is ready. To overcome this, we are going to use two Jobs. One, which is executed when the Kong is initially installed and then the another one, which is used on every upgrade. Signed-off-by: Harry Bagdi <harrybagdi@gmail.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Whenever Kong is updated using Helm, we need to ensure that migrations
are run.
For this purpose, a change has been made to run migrations using a
pre-upgrade hook.
The migration Job is being duplicated to avoid a cyclic dependency that
arises with use of pre-install or post-install hooks as detailed below:
Background:
Kong uses a database to store configuration. The migrations for the
database need to be run initially when Kong is installed and then on
every upgrade.
The pre-upgrade hooks solves the problem of running migrations on every
upgrade.
However, to run migrations during an installation has some challanges:
pre-installhook doesn't work in our case because, postgresdeployment is not available in that phase. This means that the migration
will never succeed and the deployment will always fail.
post-installhook introduces a cyclic dependency on the Kongcontainer to start.
post-installhook is executed only after all thedeployments are in ready state. But the Kong deployment will not be
ready till the migrations are run and migrations won't run till Kong
deployment is ready.
To overcome this, we are going to use two Jobs. One, which is executed
when the Kong is initially installed and then the another one, which is
used on every upgrade.
Signed-off-by: Harry Bagdi harrybagdi@gmail.com
What this PR does / why we need it:
Which issue this PR fixes
(optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close that issue when PR gets merged)Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]