Upgrading 6.2.x → 6.3.0 (introduced in v6.3.0)
This page describes the steps for upgrading an existing Local Edition 6.2.x cluster to 6.3.0 using Helm upgrade.
Before you begin, ensure the following prerequisites are met:
- Ensure the Boomi Cloud API Management - Local Edition 6.2.x cluster is up and running.
- Confirm if the Local Edition 6.2.x cluster is installed with Helm. Verify the Helm release using this command:
helm list -n <namespace>. - Confirm you have the 6.3.0 GA package: this package is available in the 6.3.0 GA installer. The
deploy/directory inside it is the Helm chart root. - All 6.3.0 container images are available to the cluster, either loaded locally for
imagePullPolicy: Alwaysor pushed to your registry. This includesapim-le-toolkit:v6.3.0, which runs the pre-upgrade hook. - The DML database user password (the same
initDBUserPasswordvalue used at install time). - Network access from the cluster to the MySQL database, unchanged from 6.2.x.
Steps to upgrade
-
Helm upgrade re-renders everything from the new chart, so you must supply every value that is customizable in the 6.2.x installation package.
-
Verify your override values: If your 6.2.x install was done by editing
deploy/values.yamlin the old 6.x.x package, instead of by passing overrides, those edits are not part of the release's user-supplied values. In this scenario, you must supply the user-supplied values into the upgrade command explicitly with--setflags or an overrides file. At minimum, verify these properties invalues.yaml: global.acceptEUA, global.apimImageRegistry, global.imagePullPolicy, global.apimClusterMode, global.k8sServiceType, global.domainSuffix (critical value — refer to the 6.3.0 Values.yaml for details), global.localDevOAuthScope, global.mysqlDatabase.host, and global.mysqlDatabase.port.
Procedure
-
Check the current release version, run:
helm get values <release> -n <namespace> -o yaml -
Upgrade the database schema for the
service_iodocstable fromapim/apim-le-toolkit. You can find the upgrade schema at<6.3.0 root directory>/upgrade/scripts/db/upgrade-schema-6.2.0_6.3.0.sqlRun the following command:
-- GraphQL schema changes for 6.3.0
ALTER TABLE service_iodocs ADD COLUMN epkey VARCHAR(255) NULL;
ALTER TABLE service_iodocs MODIFY COLUMN doc_type ENUM('IODOC', 'SWAGGER', 'GRAPHQL') NOT NULL DEFAULT 'IODOC';
ALTER TABLE service_iodocs DROP INDEX spkey;
ALTER TABLE service_iodocs ADD UNIQUE KEY uk_spkey_epkey (spkey, epkey); -
Upgrade the cluster using Helm. Run the following command:
noteIn the upgrade command, also set
--set preInstallDBPrep.executePreupgradeDbMigratetotrue. It is located at<6.3.0 root directory>/charts/preInstallDBPrep/values.yaml.helm upgrade apim ./deploy -f /<custom>-overrides.yaml \
-f /samples/overrides/preinstall-overrides.yaml \
--set preInstallDBPrep.initDBUserName=masheryonprem \
--set preInstallDBPrep.initDBUserPassword=<DML User Password> \
--set preInstallDBPrep.localDevAdminPassword=<Pass> \
--set preInstallDBPrep.executePreupgradeDbMigrate=true \
--namespace <namespace> \
--timeout 15mIf you want to inspect the job and its pod after a successful upgrade, add
--set preInstallDBPrep.hookDeletionPolicy="before-hook-creation"to the abovehelm upgradecommand before running it. This keeps the job until the nexthelm upgradetriggers the hook again.Clean these up manually when you're done, run:
kubectl delete job preupgrade-dbmigrate-6-3-0 -n <namespace>
kubectl delete configmap preupgrade-configmap -n <namespace>The 6.3.0 Helm chart ships a
pre-upgradehook in thepreInstallDBPrepsub-chart that migrates theplatformapibackend target data automatically, before any workload changes. This migration is idempotent, running it again after the data has migrated has no effect, and it logs the number of rows changed per table and stamps theupdatedcolumn of each changed row with the migration time. If the database update fails, the upgrade aborts here, before any chart resources or workloads are touched.A matching
pre-rollbackhook reverts the data onhelm rollback, subject to the limitation described in Rollback.If you want to watch the migration happen in real time, follow the pod's logs in a second terminal while the upgrade runs. The hook job deletes itself automatically on success (
hook-delete-policy: before-hook-creation,hook-succeeded), so this is your only chance to see it live:kubectl get pods -n <namespace> -w | grep preupgrade
kubectl logs -f <preupgrade-pod> -n <namespace>
Next steps
After completing the upgrade, proceed with the post-upgrade steps. Refer to Performing post-upgrade steps for more information.