You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We release [new versions of yente](https://github.com/opensanctions/yente/releases) on a regular basis in order to add new features, expand our data model and improve the scoring system. We recommend that all users of the on-premise version of the software schedule software upgrades at least **twice a year** in order to ensure proper functioning of the tool.
1
+
We release [new versions of yente](https://github.com/opensanctions/yente/releases) on a regular basis in order to add new features, expand our data model, and improve the scoring system. We recommend that all users of the on-premise version of the software schedule software upgrades at least **twice a year** in order to ensure proper functioning of the tool.
2
2
3
3
## How to upgrade
4
4
5
5
### Read the changelog
6
6
7
-
To find out what change in yente, read [the changelog published on GitHub](https://github.com/opensanctions/yente/releases). As we evolve the API, we will add new fields and endpoints, as well as deprecate old ones.
7
+
To find out what changed in yente, read [the changelog published on GitHub](https://github.com/opensanctions/yente/releases). As we evolve the API, we will add new fields and endpoints, as well as deprecate old ones.
8
8
9
9
Also read [the OpenSanctions technical changelog]({{ config.extra.opensanctions_url }}/changelog/) to find out about changes to the data model. As we evolve our data model, we regularly introduce new fields or entity types in the data model to capture additional dimensions of the entities we cover.
10
10
11
-
## Adapt your client applications
11
+
###Adapt your client applications
12
12
13
-
Ensure that your clients are compatible with the version of yente you're upgrading to and all the changes outlined in the changelog. Changes in both the data and yente functionality are carry a notice period according to [our change policy]({{ config.extra.opensanctions_url }}/docs/data/changes/).
13
+
Ensure that your clients are compatible with the version of yente you're upgrading to and all the changes outlined in the changelog. Changes in both the data and yente functionality carry a notice period according to [our change policy]({{ config.extra.opensanctions_url }}/docs/data/changes/).
14
14
15
-
## Upgrade yente
15
+
###Upgrade yente
16
16
17
-
The following instructions document the commands when running with Docker Compose. Please adapt them to your specific deployment scenario
17
+
The following instructions document the commands when running with Docker Compose. Adapt them to your specific deployment scenario.
18
18
19
-
1. Stop the yente container (`docker compose stop app`). During the upgrade, the index will at some point be switched over to the new version, which may lead to unexpected results if still serving from.
19
+
1. Stop the yente container (`docker compose stop app`). During the upgrade, the index will be rebuilt in the format of the new version, which may lead to unexpected results or crashes.
20
20
2. Update the version of the docker image used in your deployment. The version of yente is determined by the active tag of the Docker container in operation: `ghcr.io/opensanctions/yente:<version>`. Simply changing that version tag will trigger an update. If you're running in Docker compose (the default), open `docker-compose.yml` and edit the line `services.app.image`, then run `docker compose pull` to fetch the latest container.
21
21
3. Rebuild the index using `yente reindex -f` (`docker compose run app yente reindex -f`)
22
22
4. Restart the yente container: `docker compose restart app`
23
23
24
-
25
24
## Advanced: Blue-green deployment strategy
26
25
27
26
If you'd like to upgrade yente with little to no downtime, we recommend running a [blue-green deployment strategy](https://en.wikipedia.org/wiki/Blue%E2%80%93green_deployment). The basic idea is to run two versions of yente with a different `YENTE_INDEX_NAME` and switch between them. What this looks like in your environment is up to you - it could be a manual process or a full-blown CD pipeline.
@@ -33,4 +32,19 @@ If you'd like to upgrade yente with little to no downtime, we recommend running
33
32
34
33
If something isn't working right after the upgrade, you may roll back to the previous version of yente by starting the old version of yente and `YENTE_INDEX_NAME=yente-green`.
35
34
36
-
At this point, your yente is running entirely from the `yente-blue` indices. Your Eliastic will still have a bunhc of of "old" `yente-green` indices around - you may delete them. Alternatively, the next time you upgrade, you can do the same procedure but switching from `yente-blue` to `yente-green`. Your old `yente-green` indices will be cleaned up during the first reindex.
35
+
At this point, your yente is running entirely from the `yente-blue` indices. Your Elastic will still have a bunch of "old" `yente-green` indices around - you may delete them. Alternatively, the next time you upgrade, you can do the same procedure but switching from `yente-blue` to `yente-green`. Your old `yente-green` indices will be cleaned up during the first reindex.
36
+
37
+
## Upgrading from Elasticsearch 8 to 9
38
+
39
+
Elasticsearch is the search index software underlying yente. Version 9 of Elasticsearch was released in April 2025, and version 8 will be end-of-life in January 2027. Versions of yente released in 2025 or later are already compatible with both version 8 and 9 of the Elastic server, but versions of yente released after May 2026 will only be compatible with Elastic server 9. See the [official documentation for more information](https://www.elastic.co/docs/reference/elasticsearch/clients/python#_compatibility).
40
+
41
+
When **upgrading from Elasticsearch 8 to 9** in the single-node setup that is used by default in the docker-compose based deployment outlined in [our documentation on deploying yente](index.md), we have observed no issues using the following path:
42
+
43
+
1. Upgrade Elasticsearch to the latest version in the 8.x series in `docker-compose.yml` (at the time of writing, that's `8.19.13`, check [Docker Hub](https://hub.docker.com/_/elasticsearch) for the latest)
44
+
2. Restart Elasticsearch and verify everything works as expected (`docker compose up -d index`)
45
+
3. Upgrade Elasticsearch to the latest version in the 9.x series in `docker-compose.yml`
46
+
4. Restart Elasticsearch and verify everything works as expected.
47
+
48
+
For more advanced deployments of Elasticsearch, refer to the [official documentation](https://www.elastic.co/docs/deploy-manage/upgrade/deployment-or-cluster/elasticsearch).
49
+
50
+
We provide no guarantees or support around this upgrade procedure. We recommend you plan for enough downtime to allow for a full reindex on a fresh Elastic cluster, in case something does go wrong. If you require upgrades with very low or zero downtime, we recommend you set up a second instance of yente and Elastic and only switch over once you have verified that the new instance is working as expected.
0 commit comments