WebsiteTechnical Discussions

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.

topology

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:

glusterfs

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.

PrevioustestsNextfeature_environment

Last updated