2025-04-15

1

Summary of development activities

Summary of ongoing development activities.

2

X-Road 8 status update

Moving all configuration data to database

In X-Road 7, configuration data is stored in filesystem (e.g., /etc/xroad) and in database. It means that the backup and restore processes must be able to access both locations. This is not an issue when all the components run on the same host and share the same file system. Instead, the situation becomes more complicated when different components are not deployed together and the configuration files included in the backup don't reside on the same file system. For example, this is the case with X-Road 8 containerised deployment where every component is deployed in a separate container.

To simplify the backup and restore process of the containerised deployment in X-Road 8, all the possible configuration data is moved from filesystem to database. This includes configuration properties, signer data, keys, configuration anchor file, etc. Also, PostgreSQL is used as a storage backend for locally deployed OpenBao (OpenBao is used as a secure secret storage in X-Road 8). In this way, the backup of the containerised deployment consists only of the database dump.

Nevertheless, environmental variables of the containerised deployment are not be included in the backup, because they're defined using Kubernetes config maps and secrets.

Supporting Kubernetes for containerised deployments

The aim is that the containerised version of X-Road 8 can be deployed on various container orchestration platforms. However, implementing fully automated backup and restore requires that the X-Road application is able to interact with the orchestration platform via its APIs to manage the application containers. Unfortunately, there's no unified standards for the APIs and therefore, each platform has its own implementation, e.g., stopping and starting containers is handled differently by Kubernetes and Docker Compose.

Supporting fully automated backup and restore process requires including container orchestration platform-specific details in X-Road's implementation. Since Kubernetes is the most widely supported container orchestration platform and there are several Kubernetes-based services and products available (e.g., Kubernetes (K8s), AWS EKS, Azure AKS, Google GKE, Red Hat OpenShift), it has been chosen as the orchestration platform supported by X-Road. This means that even if the X-Road Docker images can be run anywhere, there are Kubernetes specific features which will limit X-Road’s ease of use with other orchestrators. For example, deploying the Security Server using some other orchestrator is possible, but in that case the application level backup/restore features are not available and the administrator must implement the backup/restore using other tools.

3

Open topics

Discussion on open topics.

Next meetings

• Meeting 34, May 15 2025, 15:00-16:00 (EEST, UTC+3)

• Meeting 35, June 18 2025, 15:00-16:00 (EEST, UTC+3)

• Meeting 36, August 20 2025, 15:00-16:00 (EEST, UTC+3)

• Meeting 37, September 17 2025, 15:00-16:00 (EEST, UTC+3)

• Meeting 38, October 22 2025, 15:00-16:00 (EEST, UTC+3)

• Meeting 39, November 19 2025, 15:00-16:00 (EET, UTC+2)

• Meeting 40, December 17 2025, 15:00-16:00 (EET, UTC+2)

• Meeting 41, January 21 2026, 15:00-16:00 (EET, UTC+2)

• Meeting 42, February 18 2026, 15:00-16:00 (EET, UTC+2)

• Meeting 43, March 18 2026, 15:00-16:00 (EET, UTC+2)