acceptance_tests
Last updated: 2025-07-08 01:05:43.327161 File source: link on GitLab
Acceptance tests architecture
Introduction
This document aims to consolidate the architecture supporting the acceptance tests. This architecture can be seen as a revised and simplified architecture of the now phased out Feature Environment.
The decisions supporting this new architecture can be found in the Acceptance Tests ADR
Architecture
The acceptance tests are executed from the repository of the target project to be tested. The pipeline executes make run-acceptance
which executes the tests. The actual implementation of the tests may vary with time, but currently these tests are composed by gherkin features just as before with the feature environment, but it uses godog as the framework to implement the feature steps.
The tests are responsible for deploying and managing the virtual machines and the network. They interact with these virtual machines using the incus exec
interface provided by the incus sdk for golang.
Infrastructure
The incus server is hosted under test.nunet.io. The server is a baremetal server managed by Hetzner.
The configuration of the server is as dry as possible:
Ubuntu 24.04
ubuntu
user:passwordless sudo
incus-admin
group
Incus installed with
apt install incus incus-tools qemu-system
Configured with unpriviledged containers
Authentication
The authentication between the test execution and the incus servers are done via TLS certificates. A configuration file for the acceptance tests is encoded as base64 and written to DMS_ACC_TEST_CONFIG_B64
, which is a CI/CD variable that belongs to the Nunet group. The file is then reconstructed and the file path is written to the environment variable DMS_ACC_TEST_CONFIG_FILE
, which is then used by the acceptance tests to load the config file.
The configuration file for the acceptance tests has the following structure:
incus_hosts:
- host: 10.0.0.0
port: 8443
client_cert: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
client_key: |
-----BEGIN EC PRIVATE KEY-----
...
-----END EC PRIVATE KEY-----
server_cert: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
To generate these certificates, a token must first be created with incus config trust add
. The token should then be used in a docker container, so that it generates a new client certificate. incus remote add hetzner-test test.nunet.io:8443 --token ${TOKEN}
generates the required certificates.
Once that is done, inside the container the certificates are deployed into ~/.config/incus
. Client cert and client key reside in ~/.config/incus/client.crt
and ~/.config/incus/client.key
respectively. The server cert can be found in ~/.config/incus/servercerts/hetzner-test.crt
.
Copy the contents of these files into their respective fields in the yaml config file.
A convenience tool hosted under infrastructure/acc-tests-config-maker
can be used to generate these configuration files from pre-existing client and server certificates.
GlusterFS
The storage package of DMS offers from many functionalities related to accessing different file systems for data persistency a way to directly manage the lifecycle of GlusterFS volumes.
It's important to assess the correct behavior of these features through the acceptance tests.
The following diagram shows how DMS is required on the GlusterFS server. It receives volume requests through the actor behaviors /dms/volume/create
, /dms/volume/delete
and /dms/volume/start
and delegates to glusterd
the creation of volumes, which are then available to be mounted in ensembles in client DMS's:
In the graph above, deploy using glusterfs Client CA
is done with an ensemble similar to DMS storage/volume/README.md:
allocation:
type: service
# ...
volume:
- type: glusterfs
name: Volume X
servers: ["${hostname}"]
mount_destination: "/home"
client_private_key: /path/to/client.key
client_pem: /path/to/client.pem
client_ca: /path/to/client.ca
Therefore the acceptance tests should be responsible for provisioning the GlusterFS servers to support the tests.
Repo nunet/test-suite issue 206 tracks the manual creation of the glusterfs servers with a fixed version of DMS that has the functionality to interact with glusterd
.
Issue 207 tracks the implementation of the automatic provisioning of the GlusterFS servers via the acceptance tests.
Last updated