Skip to content

upgrading.md

Latest commit

 

History

History
68 lines (43 loc) · 3.88 KB

upgrading.md

File metadata and controls

68 lines (43 loc) · 3.88 KB

Upgrading

Before upgrading, please review the changelog for any breaking or notable changes in the releases between your current version and the one you are upgrading to. These changes can be found on the Release page.

All operator versions pin to the most recent eda-server and ui image version at the time of the operator release by default. This is so that the application version only changes when you upgrade your operator (unless overriden).

To find the version of eda-server that will be installed by the operator, check the version specified in the DEFAULT_EDA_VERSION and DEFAULT_EDA_UI_VERSION variable for that particular release. You can do so by running the following command

EDA_OPERATOR_VERSION=1.0.1
docker run --entrypoint="" quay.io/ansible/eda-server-operator:$EDA_OPERATOR_VERSION bash -c "env | egrep "DEFAULT_EDA_VERSION|DEFAULT_EDA_UI_VERSION"

Follow the installation instructions ('make deploy', 'kustomization', etc.) using the new release version to apply the new operator yaml and upgrade the operator. This will in turn also upgrade your EDA deployment.

For example, if you installed with kustomize, you could modify the version in your kustomization.yaml file from 1.0.0 to 1.0.1, then apply it.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - config/default

# Set the image tags to match the git version from above
images:
  - name: quay.io/ansible/eda-server-operator
    newTag: 1.0.1

# Specify a custom namespace in which to install EDA
namespace: eda

Then run this to apply it:

kustomize build . | kubectl apply -f -

Backup

The first part of any upgrade should be a backup. Note, there are secrets in the pod which work in conjunction with the database. Having just a database backup without the required secrets will not be sufficient for recovering from an issue when upgrading to a new version. See the backup role documentation for information on how to backup your database and secrets.

In the event you need to recover the backup see the restore role documentation. Before Restoring from a backup, be sure to:

  • delete the old existing EDA CR
  • delete the persistent volume claim (PVC) for the database from the old deployment, which has a name like postgres-15-<deployment-name>-postgres-15-0

Note: Do not delete the namespace/project, as that will delete the backup and the backup's PVC as well.

Redis Deprecation

Starting with this version, the EDA operator no longer deploys or uses Redis. EDA now uses dispatcherd, a PostgreSQL pg_notify-based task queuing system that eliminates the need for a separate Redis instance.

What happens automatically during the upgrade:

  • The operator deletes any existing managed Redis Deployment (<name>-redis), Service (<name>-redis-svc), and Secret (<name>-redis-configuration).
  • No data migration is required — Redis was used only for transient message queuing (emptyDir storage), and all durable task state is persisted in PostgreSQL.

What you need to do:

  • Remove the redis section from your EDA CR spec when convenient. If your CR still contains a redis section, the operator will log a deprecation warning and ignore it — the upgrade will proceed normally. You should remove the redis: block at your earliest convenience.
  • Decommission any external Redis instance that was dedicated to EDA. No EDA component connects to Redis anymore.
  • The redis_image and redis_image_version CR fields are deprecated and ignored.

Note: The redis fields remain in the CRD schema for backward compatibility but are marked as deprecated. They will be removed in a future apiVersion.

For more details, see the Redis Deprecation Notice.