Structuring multiple boards in environment config

I am setting up a lab with 8 different hardware that are similar from a LabGrid point-of-view. Beside these 8 boards, I have 8 helper hardware (1 for each board) that are exactly the same (BeagleBone Black).

My goal is to provide an environment file to my colleagues so they are able to work on any board.

The environment file looks like this:

targets:
  board1:
    resources:
      RemotePlace:
        name: board1
    drivers:
      - ModbusCoilDriver: {}
      - ModbusCoilDriver:
          name: power
          bindings:
            coil: power
      - DigitalOutputPowerDriver:
          bindings:
            output: power
      - SerialDriver: {}
      - UBootDriver:
          autoboot: Type password
          interrupt: e
          prompt: '=> '
          bootstring: Starting kernel ...
          boot_commands:
            usb: run usbbootcmd
      - ShellDriver:
          prompt: 'user@localhost:~# '
          login_prompt: '[^ ]+ login: '
          username: user
          password: password
      - SSHDriver: {}
      - UBootStrategy: {}
  board2:
    resources:
      RemotePlace:
        name: board2
    drivers:
      - ModbusCoilDriver: {}
      - ModbusCoilDriver:
          name: power
          bindings:
            coil: power
      - DigitalOutputPowerDriver:
          bindings:
            output: power
      - SerialDriver: {}
      - UBootDriver:
          autoboot: Type password
          interrupt: e
          prompt: '=> '
          bootstring: Starting kernel ...
          boot_commands:
            usb: run usbbootcmd
      - ShellDriver:
          prompt: 'user@localhost:~# '
          login_prompt: '[^ ]+ login: '
          username: user
          password: password
      - SSHDriver: {}
      - UBootStrategy: {}
# Repeat the last 28 lines for the remaining 6 boards
  board1-bbb:
    resources:
      RemotePlace:
        name: board1-bbb
    drivers:
      - ModbusCoilDriver: {}
      - DigitalOutputPowerDriver: {}
      - SSHDriver: {}
  board2-bbb:
    resources:
      RemotePlace:
        name: board2-bbb
    drivers:
      - ModbusCoilDriver: {}
      - DigitalOutputPowerDriver: {}
      - SSHDriver: {}
# Repeat the last 8 lines for the remaining 6 bbb boards

I can reduce the repetition using yaml syntax

targets:
  board1:
    resources:
      RemotePlace:
        name: board1
    drivers: &linux
    - ModbusCoilDriver: {}
    - ModbusCoilDriver:
      name: 'power'
      bindings:
        coil: 'power'
    - DigitalOutputPowerDriver:
      bindings:
        output: 'power'
    - SerialDriver: {}
    - UBootDriver:
      autoboot: "Type password"
      interrupt: 'e'
      prompt: '=> '
      bootstring: 'Starting kernel ...'
      boot_commands:
        usb: run usbbootcmd
    - ShellDriver:
      prompt: 'user@localhost:~# '
      login_prompt: '[^ ]+ login: '
      username: 'user'
      password: 'password'
    - SSHDriver: {}
    - UBootStrategy: {}
  board2:
    resources:
      RemotePlace:
        name: board2
    drivers: *linux
# Repeat the last 5 lines for the remaining 6 boards
  board1-bbb:
    resources:
      RemotePlace:
        name: board1-bbb
    drivers: &bbb
    - ModbusCoilDriver: {}
    - DigitalOutputPowerDriver: {}
    - SSHDriver: {}
  board2-bbb:
    resources:
      RemotePlace:
        name: board2-bbb
    drivers: *bbb
# Repeat the last 5 lines for the remaining 6 bbb boards

One way that seems more intuitive and reduce repetition is for RemotePlace to support a list:

targets:
  linux:
    resources:
      RemotePlace:
        name:
        - board1
        - board2
        - board3
        - board4
        - board5
        - board6
        - board7
        - board8
    drivers:
    - ModbusCoilDriver: {}
    - ModbusCoilDriver:
      name: 'power'
      bindings:
        coil: 'power'
    - DigitalOutputPowerDriver:
      bindings:
        output: 'power'
    - SerialDriver: {}
    - UBootDriver:
      autoboot: "Type password"
      interrupt: 'e'
      prompt: '=> '
      bootstring: 'Starting kernel ...'
      boot_commands:
        usb: run usbbootcmd
    - ShellDriver:
      prompt: 'user@localhost:~# '
      login_prompt: '[^ ]+ login: '
      username: 'user'
      password: 'password'
    - SSHDriver: {}
    - UBootStrategy: {}
  bbb:
    resources:
      RemotePlace:
        name:
        - board1-bbb
        - board2-bbb
        - board3-bbb
        - board4-bbb
        - board5-bbb
        - board6-bbb
        - board7-bbb
        - board8-bbb
    drivers:
    - ModbusCoilDriver: {}
    - DigitalOutputPowerDriver: {}
    - SSHDriver: {}

Another way is for the environment configuration file to use Jinja2 as a preprocessor, like the exporter configuration file:

# for idx in range (0, 8)
targets:
  board{{ 1 + idx }}:
    resources:
      RemotePlace:
        name: board{{ 1 + idx }}
    drivers: &linux
    - ModbusCoilDriver: {}
    - ModbusCoilDriver:
      name: 'power'
      bindings:
        coil: 'power'
    - DigitalOutputPowerDriver:
      bindings:
        output: 'power'
    - SerialDriver: {}
    - UBootDriver:
      autoboot: "Type password"
      interrupt: 'e'
      prompt: '=> '
      bootstring: 'Starting kernel ...'
      boot_commands:
        usb: run usbbootcmd
    - ShellDriver:
      prompt: 'user@localhost:~# '
      login_prompt: '[^ ]+ login: '
      username: 'user'
      password: 'password'
    - SSHDriver: {}
    - UBootStrategy: {}
  board{{ 1 + idx }}-bbb:
    resources:
      RemotePlace:
        name: board{{ 1 + idx }}-bbb
    drivers: &bbb
    - ModbusCoilDriver: {}
    - DigitalOutputPowerDriver: {}
    - SSHDriver: {}
# endfor

I like the 'RemotePlace list' better because it emphasis the role and make it easy to assign boards to another role, should this be needed in the future.

What do you think about this?

How does you environment file look like and how do you maintain/share it?

No file, test, or entry point is named. Start by locating environment configuration loading and the exporter configuration's Jinja2 preprocessing, then trace how RemotePlace names and target definitions are parsed. Done means the project has an agreed approach for reducing repeated board configuration, with its behavior documented and tested.