Skip to content

17.1.x to 18.0.0

The load balancer moves from Nginx to Traefik

The configuration files now ship a 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),
    • for HTTPS, copy your server.crt and server.crt.key files to the traefik/certs/ folder (see 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 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, 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, 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 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:

  1. Remove its container, as described in 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.

When email activation 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 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:

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 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.

Data retention settings have new keys

The 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 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.

See the 18.0.0 release notes for the full list of changes.