Skip to content

System Engineer

The system engineers role is to deploy ETOS and maintain the infrastructure that ETOS relies on.

The name System Engineer might be a bit tacky or weird, and what we really want to say with it is more "a person or team that is responsible for the deployment and infrastructure of ETOS", but it was difficult to put that into a single name.

System maintainer might be more proper, but may allude to the system engineer also sending patches upstream (which does not have to be the case).
System owner is also a contender, but we chose engineer so that is what we are continuing with.

Responsibilities of a system engineer

  • Deploying ETOS
  • Maintaining the infrastructure that ETOS relies on
  • Creating any domain specific provider that may be necessary

Installation

To install ETOS you can read the guide here
We should also take care to follow the production guide.

Infrastructure

In addition to the production considerations, there may be other things that are required for ETOS to run as expected.

ETOS will deploy a serviceable version with the Cluster specification that also adds Providers to the cluster. These providers make sure that we can configure IUTs, execution spaces and log areas to our preferences.
The default providers that ETOS will deploy are a generic IUT provider which does nothing of note, an execution space provider that tells ETOS to start tests in Kubernetes and a log area deployed by the ETOS API.

Custom providers

In certain cases it might be required to create custom providers for any sort. Maybe you need to long-term store the artifacts generated by the tests on a different server than ETOS provides you, maybe you need to start your tests on a Jenkins instance instead of in Kubernetes or maybe you have a complex system for leasing devices with the IUT software attached. For these cases you probably need to create custom providers in order to handle that situation.

A provider is a program running in a docker container whose job it is to create the Iut, LogArea or ExecutionSpace resources in Kubernetes.

There are three types of providers.

ExecutionSpace

Where the tests are executed, including deployed extra services required for the tests. The Execution space provider will prepare the environment for testing and start up the Test runner container which will install the ETOS test runner. This provider will also make sure all the environment variables are correctly set.

LogArea

Where the test artifacts and logs are stored. The ETOS test runner uploads all files that are generated to a file storage server, this is the description of the file storage server and how to upload to it. The log area provider will prepare a space on the file server and provide the ETOS test runner with instructions.

IUT

What the tests are testing. This can be software or software + hardware combinations. The IUT provider will prepare the software for test and make it available to the ETOS test runner. In most cases the IUT provider is not necessary, especially if one is only running tests against a git repository. However there are some cases where an IUT provider is necessary such as if the software needs to be spun up an prepared before execution or if the software needs to be installed onto some hardware device for it to be testable.

For a guide on how to create a custom provider please look here

GraphQL queries and artifacts

It is the responsibility of the system engineer to make sure that there is an event repository available to ETOS. ETOS only supports the Eiffel GraphQL API at the moment so that is what is necessary.

In order for the test engineers to properly execute tests using ETOS, there needs to be EiffelArtifactCreatedEvents available in the event repository. The identity of the IUT is the meta.id of the event and is a required input when running tests.

If you deployed ETOS locally then there will be artifacts already available in the deployed event repository, but in a real deployment of ETOS it is up to the system engineer to populate the event repository with these events.

To publish an event to the event repository, an EiffelArtifactCreatedEvent JSON structure needs to be created and published on the RabbitMQ exchange that the Eiffel GraphQL API listens to. The storage component of the API will then store the event in the repository, making it available in the API.

Query the API

To query the API in order to find out whether there are any events available or to find a specific event needed for the test execution copy the below samples.

Simple query, last 10.

{
  artifactCreated(last: 10) {
    edges {
      node {
        data {
          identity
        }
        meta {
          id # Used by ETOS
        }
      }
    }
  }
}

Query specifying a certain software version

{
  artifactCreated(search: "{'data.identity': 'pkg:my/package@1.0.1'}") {
    edges {
      node {
        data {
          identity
        }
        meta {
          id # Used by ETOS
        }
      }
    }
  }
}