> OctoPerf Enterprise Edition - Migration from 17.1.x to 18.0.0.

Source: https://api.octoperf.com/doc/on-premise-infra/migration/17.1.x-to-18.0.0/

# 17.1.x to 18.0.0

## The load balancer moves from Nginx to Traefik

The [configuration files](https://api.octoperf.com/doc/on-premise-infra/download/) now ship a [Traefik](https://traefik.io/traefik/) load balancer instead of Nginx: the `nginx` folder is replaced by a `traefik` folder, with `traefik.yml` and `dynamic.yml`. Traefik routes the same paths as before, and no image needs to be built anymore.

To upgrade a Docker Compose installation:

1. In your current installation folder, stop the stack with `make down`. **Do this before replacing the files**: otherwise the former `nginx` container keeps running, holds the port, and Traefik cannot start. If it already happened, run `docker compose down --remove-orphans`.
2. Grab the new configuration files and copy your `config` and `license` folders into them.
3. If you changed the Nginx configuration, report your changes in the `traefik` folder:
    - a custom port goes in `traefik/traefik.yml` (see [Server Port](https://api.octoperf.com/doc/on-premise-infra/configuration/#server-port)),
    - for HTTPS, copy your `server.crt` and `server.crt.key` files to the `traefik/certs/` folder (see [HTTPS setup](https://api.octoperf.com/doc/on-premise-infra/tutorials/https-setup/)). The HTTPS version now also listens on port `80` to redirect HTTP requests to HTTPS: make sure this port is free.
4. Start the stack with `make`.

On Kubernetes, the [example configuration files](https://api.octoperf.com/doc/on-premise-infra/download/) now expect a Traefik v3.5 or later ingress controller. Their `README.txt` lists the Traefik settings they require, in particular strict prefix matching: without it, the `/doc` ingress captures the requests of the load generators and tests fail to run.

## Your load generators must be upgraded with the server

The agent (`octoperf/docker-agent`) and the JMeter images move to `18.0.0`, and K6 virtual users run in the new `octoperf/k6:18.0.0` image. Pull the load generator images again on every machine that runs an [on-premise agent](https://api.octoperf.com/doc/on-premise-agent/provider-type/on-premise/), and restart the agents. If you launch load generators on Kubernetes, update the image tags in your own configuration too.

## Kubernetes agent: the load generator settings have new keys

If you run the [Kubernetes agent](https://api.octoperf.com/doc/on-premise-agent/provider-type/on-premise/#kubernetes-agent), the resources of the load generator pods move from `octoperf.kubernetes.pod.resources` to `octoperf.container.resources`. **The agent `18.0.0` ignores the former keys**, including when they are set as environment variables:

| Former key (17.1.x) | New key (18.0.0) |
|---------------------|------------------|
| `octoperf.kubernetes.pod.resources.requests.memory-factor` | `octoperf.container.resources.requests.memory-factor` |
| `octoperf.kubernetes.pod.resources.limits.memory-factor` | `octoperf.container.resources.limits.memory-factor` |
| `octoperf.kubernetes.pod.resources.limits.cpu` | `octoperf.container.resources.limits.cpu` |

- `limits.cpu` now sets the CPU limit only, and the new `requests.cpu` sets the CPU request. With no request, Kubernetes uses the limit as the request, as before.
- The security context of the load generator pods and containers can now be configured. Nothing changes until you set it.

The [README of the Helm chart](https://github.com/OctoPerf/helm-charts/tree/master/kubernetes-agent#upgrading-to-1800) details these changes.

## Your on-premise agents must be relaunched with a new token

`18.0.0` hardens the security of on-premise agents and **renews the secret that signs agent tokens**. At the first start of `18.0.0`, the server generates a new random secret, stores it encrypted in the database, and shares it with every backend node.

As a consequence, **the agents installed before `18.0.0` stop connecting after the upgrade**: their token was signed before the upgrade and is refused. Restarting them is not enough, and the automatic agent upgrade cannot help either, as it needs the agent to connect first. For each [on-premise agent](https://api.octoperf.com/doc/on-premise-agent/provider-type/on-premise/):

1. Remove its container, as described in [Remove and recreate the agent](https://api.octoperf.com/doc/on-premise-agent/provider-type/on-premise/#remove-and-recreate-the-agent).
2. Launch it again with a new installation command, taken from the **Add Agent** button of the providers list: this command carries a newly generated token.

!!! warning
    The secret of the installation is stored in the `configentry` index of the database. **Include this index in your backups**: if the database is restored without it, the server generates a new secret at startup, and every agent must be relaunched again. To change the secret on purpose, see [Rotate the secret](https://api.octoperf.com/doc/on-premise-infra/configuration/#rotate-the-secret).

## Pending account activation links must be requested again

When [email activation](https://api.octoperf.com/doc/on-premise-infra/configuration/#user-management) is enabled, activation links are now single-use and stay valid for at most 1 day. They do not survive a full restart of the server: a link sent before the upgrade no longer works. The user can ask for a new activation email from the page the link opens.

## Rate limit settings have new keys

[Rate limits](https://api.octoperf.com/doc/on-premise-infra/configuration/#rate-limits) are now configured under `octoperf.rate-limit`, with a `duration` and a `capacity` for each limit. **The former keys are no longer read, and no error warns about them**: if your `application.yml` sets one of them, move it to its new key.

| Former key (17.1.x) | New keys (18.0.0) |
|---------------------|-------------------|
| `login.max-attempts` | `octoperf.rate-limit.users.login.capacity` |
| `login.rate-limit` | `octoperf.rate-limit.users.login.duration` |
| `users.email.rate-limit` | `octoperf.rate-limit.users.account-mails.duration`, with `capacity: 1` to keep the former behavior |
| `notifications.trial.rate-limit` | `octoperf.rate-limit.notifications.trial.duration`, with `capacity: 1` to keep the former behavior |

The account emails (activation, password reset) and the test notifications **are no longer limited by default**. Before `18.0.0`, they were limited to one email per minute per address, and one test notification every 5 seconds per user. To keep these limits, add them to your `application.yml`:

```yaml
octoperf:
  rate-limit:
    users:
      account-mails:
        duration: 1m
        capacity: 1
    notifications:
      trial:
        duration: 5s
        capacity: 1
```

The limit on failed login attempts is unchanged: `10` attempts per `10m` from the same IP address.

`18.0.0` also brings optional [quotas](https://api.octoperf.com/doc/on-premise-infra/configuration/#quotas) on the number of workspaces per account and projects per workspace. None is set by default.

## The nightly cleanup of old recordings is removed

The nightly batch `octoperf.eviction.http-recorded`, which deleted the recorded requests and responses of the Virtual Users last modified 12 to 24 months ago, is removed. It was disabled by default. **Its keys are no longer read, and no error warns about them**: if your `application.yml` sets `octoperf.eviction.http-recorded`, remove it.

The recorded requests and responses are still deleted with their Virtual User or their project, and a daily task deletes those older than their [retention](https://api.octoperf.com/doc/on-premise-infra/configuration/#recorded-and-validation-data-retention).

## Data retention settings have new keys

The [retention](https://api.octoperf.com/doc/on-premise-infra/configuration/#recorded-and-validation-data-retention) of the validation and recorded requests and responses is now configured under `octoperf`. **The former keys are no longer read, and no error warns about them**: if your `application.yml` sets one of them, move it to its new key.

| Former key (17.1.x) | New key (18.0.0) |
|---------------------|------------------|
| `validation.retention-days` | `octoperf.validation.retention-days` |
| `recorded.retention-days` | `octoperf.recorded.retention-days` |

The retention of recorded requests and responses, 2 years by default, is now counted from their import into OctoPerf. Before `18.0.0`, it was counted from the date they were originally recorded: a recording imported more than 2 years after it was made was deleted the next day.

## If you call the REST API

Virtual User validations take a new body, with their provider, location, iterations and engine settings. A scenario with an error in its [scenario check](https://api.octoperf.com/doc/runtime/edit-scenario/scenario-check/) is refused at launch with a `400`, from every launch route and the scheduler, and the two provider capacity endpoints are removed: call the sanity check of the scenario instead. Every change is listed in [REST API changes: 17.1.0 to 18.0.0](https://api.octoperf.com/doc/api-changes-18.0/).

See the [18.0.0 release notes](https://api.octoperf.com/doc/release-notes/) for the full list of changes.