# Upgrading to DefectDojo Version 2.53.x

## Helm Chart Changes

- This release introduces an important change to the Helm chart configuration for the initializer job.
- DefectDojo `2.52.0` replaced Redis with Valkey in `docker-compose` deployment. DefectDojo `2.53.0` (chart `1.9.0`) is replacing it in HELM charts.
- Add support for HPA and PDB

#### HPA & PDA

Added Helm chart support for Celery and Django deployments for Horizontal Pod Autoscaler using `.autoscaling` fields under each section. And Pod Disruption Budget using `.podDisruptionBudget` for any of Celery Beat/Worker or Django deploy

### Breaking changes

#### Valkey

##### Renamed values

HELM values had been changed to the following:

- `createRedisSecret` → `createValkeySecret`
- `redis.enabled` → `valkey.enabled`
- `redis.auth.existingSecret` → `valkey.auth.existingSecret`, plus value is pointing to secret `defectdojo-valkey-specific` now
- `redis.auth.existingSecretPasswordKey` → `valkey.auth.existingSecretPasswordKey`, plus value is pointing to secret `valkey-password` now
- `redis.auth.password` → `valkey.auth.password`
- `redis.master.service.ports.redis` → `valkey.service.port`
- `redis.sentinel...` → `valkey.sentinel...`
- `redis.tls...` → `valkey.tls...`

The whole subchart is based on [`cloudpirates-valkey`](https://artifacthub.io/packages/helm/cloudpirates-valkey/valkey), so all additional values can be found there.

If an external Redis instance is being used, set the parameter `valkey.enabled` to `False`. The parameters `redisServer` and `redisParams` remain available and function as before. Additionally, `redisScheme` and `redisPort` have been introduced to accommodate users requiring these configurations.

##### How to migrate to Valkey

0. As always, perform a backup of your instance  
1. If you would like to be 100% sure that you do not miss any async event (triggered deduplication, email notification, …) it is recommended to perform the following substeps (if your system is not in production and/or you are willing to miss some notifications or postpone deduplication to a later time, feel free to skip these substeps)  
0\. Perform the following steps with your previous version of HELM chart (not with the upgraded one - you might lose your data)  
1. Downscale all producers of async tasks:  
      - Set `django.replicas` to 0 (if you used HPA, adjust it based on your needs)  
      - Set `celery.beat.replicas` to 0 (if you used HPA, adjust it based on your needs)  
      - Do not change `celery.worker.replicas` (they are responsible for processing your async tasks)  
2. Wait until the processing queue is empty (choose one of the following methods):  
      - ``kubectl exec statefulset/defectdojo-redis-master -c redis -- redis-cli -a `kubectl get secret defectdojo-redis-specific -o go-template='{{index .data "redis-password" | base64decode}}'` llen celery`` – should output 0 (if your HELM chart used a different name, adjust the command based on your environment)  
      - `kubectl logs deployment/defectdojo-celery-worker -c celery --all-pods=true --follow` – should stop outputting new task logs  
2. Replace values based on the _Renamed values_ part, update the chart version, and set the number of replicas back. Be aware that Valkey is using a password from the new location, and if you use `createRedisSecret`/`createValkeySecret` password will be regenerated. If you stored this password somewhere else, it will not be valid anymore.  
3. Enjoy DefectDojo

#### Initializer Annotation Handling

- **Renamed initializer annotations**: The `initializer.annotations` field has been renamed to `initializer.podAnnotations` for clarity and consistency with other DefectDojo resources.  
- **Merged annotation support**: Global `extraAnnotations` are now automatically merged with the initializer’s `podAnnotations` to ensure consistent annotation handling across all resources.

> The previous implementation did not merge global `extraAnnotations` with the initializer job’s pod annotations, causing inconsistencies in annotation management.

##### Moved values

The following Helm chart values have been modified in this release:

- `initializer.annotations` → `initializer.podAnnotations` (applies to Pod template metadata within the Job)

Note: `initializer.jobAnnotations` affects the Job spec metadata, while `initializer.podAnnotations` affects the Pod template metadata within the Job.

##### Migration

If you were using:

```yaml
initializer:
  annotations:
    foo: bar
```

Update to:

```yaml
initializer:
  podAnnotations:
    foo: bar
```

Both `extraAnnotations` and `initializer.podAnnotations` will now be properly applied to the initializer pod.

## Reimport updates fields fix_available and fix_version

Reimport will update existing findings `fix_available` and `fix_version` fields based on the incoming scan report.

## Batch Deduplication

Before 2.53.0 Defect Dojo has been deduplicating new or updated findings one-by-one. This works well for small imports and has the benefit of an easy to understand codebase and test suite. For larger imports however the performance is bad and resource usage is (very) high. A 1000+ finding import can cause a celery worker to spend minutes on deduplication.

PR [13491](https://github.com/DefectDojo/django-DefectDojo/pull/13491) changes the deduplication process for import and reimport to be done in batches. This biggest benefit is that there now will be 1 database query per batch (1000 findings), instead of 1 query per finding (1000 queries).

A quick test with the `jfrog_xray_unified/very_many_vulns.json` samples scan (10k findings) shwo the obvious huge improvement in deduplication time. Please note that we’re not only doing this for performance, but also to reduce the resources (cloud cost) needed to run Defect Dojo.

initial import (no duplicates):

| branch | import time | dedupe time | total time |
| --- | --- | --- | --- |
| dev | ~200s | ~400s | ~600s |
| dedupe-batching | ~190s | _~12s_ | ~200s |

second import into the same product (all duplicates):
initial import (no duplicates):

| branch | import time | dedupe time | total time |
| --- | --- | --- | --- |
| dev | ~200s | ~400s | ~600s |
| dedupe-batching | ~190s | _~180s_ | ~370s |

There are no other special instructions for upgrading to 2.53.x. Check the [Release Notes](https://github.com/DefectDojo/django-DefectDojo/releases/tag/2.53.0) for the contents of the release.