Upgrades
An upgrade is a helm upgrade of one product’s chart, or an Argo CD sync of
a changed version. Upgrade one product at a time and check it before the
next.
Before every upgrade
Section titled “Before every upgrade”- Read the product’s release notes for the versions you skip. Before 1.0, a minor version may change settings; the notes say what to change. TinyConductor and TinyGuard publish theirs with their guides.
- Back up the product’s database, and check that you have the offline copy of its encryption key. Going back past a database change means restoring this backup.
- Look up the new image digest and change it, with the chart version, in your values.
Running it
Section titled “Running it”helm upgrade tinyconductor oci://registry.tinyfactory.ai/tinyblox/charts/tinyconductor \ --version <new version> -n tinyblox -f conductor.yaml --wait --wait-for-jobs --timeout 20mWhat happens:
- The migration Job brings the database to the new release. If it fails, nothing else changes and the running pods keep serving.
- The pods are replaced. Each product’s guide says whether it can replace them one at a time with no interruption, or needs a short stop for this release.
With Argo CD, change targetRevision and the digest in Git; the sync does
the same steps.
The order across products
Section titled “The order across products”Upgrade in the install order: TinyGuard, TinyVault, TinyConductor, the connector runtime. A release that needs a newer version of another product says so in its notes.
Rolling upgrades
Section titled “Rolling upgrades”coming Every product is moving to the same upgrade promise: old and new release running side by side on the same database, pods replaced one at a time, nothing stopped. A database change that would break the old release is split over two releases, so the old release keeps working during the roll. A product refuses an upgrade that skips more than one release where that would break, and says which release to upgrade to first.
Until a product’s release notes say it upgrades this way, follow the steps in its own upgrade guide; TinyConductor 0.1 to 0.2, for example, needs its pods stopped during the upgrade.
Going back
Section titled “Going back”- Within one release (the new release did not change the database in a
way the old one cannot read):
helm rollback <release>, or revert the version in Git. - Past a database change: restore the backup taken before the upgrade, with the encryption key from the same time, then install the old version.