Version 2.2.0 - Helm Chart and watchdog for update process

This version adds an Helm Chart to help with Kubernetes deployment and a new watchdog to allow a new update to be launched after a stucked one without manual action.

Helm Chart

This chart is not yet published to a repository but it will be documented as soon as it is done.

Update Watchdog

Previously, if the process running the update was killed, the update was not closed, preventing any further launch. You had to end the previous update by calling sirene update finish-error.

Now, if an update is running and the status was not updated for more than one hour, it will be considered as stucked, and will be automatically terminated, and the new update process will continue normally.

Full Changelog: v2.1.2...v2.2.0

Version 2.1.2 - Maintenance release

This release only upgrades dependencies.

Full Changelog: v2.1.1...v2.1.2

Version 2.1.1 - Maintenance release

This release only upgrades dependencies.

Full Changelog: v2.1.0...v2.1.1

Version 2.1.0 - New logs and Tokio 1.0

Changes:

• Using tracing instead of log
• Update tokio to 1.0

Full Changelog: v2.0.0...v2.1.0

Version 2.0.0 - Daily updates, async and performances

This major version adds daily updates, asynchronous support and a 7x performance increase.

Daily updates

To enable daily updates:

1. Go to https://api.insee.fr/catalogue/
2. Create an account or sign in
3. Create an application on this portal
4. Subscribe this application to the Sirene - V3 API
5. Generate a key pair in the application details
6. Copy the key from the curl example and paste it in .env: Authorization: Basic [INSEE_CREDENTIALS]

Asynchronous support

When updating data using the admin API, the parameters have a new asynchronousparameter. If it is set to true, the update endpoint will immediately return the following:

Status: 202 Accepted
Location: /admin/update/status?api_key=string
Retry-After: 10

[Initial status for the started update]

GET /admin/update/status?api_key=string

If an update is in progress, the status code will be 202, otherwise 200. It can be used with Azure Logic Apps for example.

Benchmark

v2.0.0

Running 8s test @ http://127.0.0.1:3000/v3/etablissements/79837235500023
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    13.78ms    6.44ms  62.20ms   70.75%
    Req/Sec     1.84k   159.94     2.21k    86.09%
  Latency Distribution
     50%   13.52ms
     75%   17.48ms
     90%   21.69ms
     99%   31.01ms
  116922 requests in 8.01s, 386.26MB read
  Socket errors: connect 0, read 65, write 0, timeout 0
Requests/sec:  14603.06
Transfer/sec:     48.24MB

v1.1.0

Running 8s test @ http://127.0.0.1:3000/v3/etablissements/79837235500023
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    53.60ms   67.86ms 547.09ms   95.61%
    Req/Sec   439.63    134.35     0.93k    80.43%
  Latency Distribution
     50%   41.29ms
     75%   47.53ms
     90%   52.88ms
     99%  441.28ms
  16502 requests in 8.11s, 55.33MB read
  Socket errors: connect 0, read 16599, write 0, timeout 0
Requests/sec:   2035.02
Transfer/sec:      6.82MB

New Contributors

• @Ldouziech made their first contribution in #128

Full Changelog: v1.1.0...v2.0.0

HTTP Maintenance API and logging

This release comes with a new HTTP Maintenance API and an update logging system.

If you provide and API_KEY when launching serve, the maintenance HTTP API will be automatically enabled and you will be able to launch an update with an HTTP call.

To avoid server overload, the system automatically prevents more than one update at a time, even if it's launched from CLI.

Each update is now logged in the database and a full report is stored and returned after an update.

The full documentation is available on the README file.

Full Changelog: v1.0.3...v1.1.0