RFC: Deployer tooling

[julianschuler]

Please add all your deployer tooling improvement ideas to this issue thread.

See #1479 for the initial issue.

[oleflb]

The way I see this, the problem can be divided into different stages:

• Pregame

  • A better way to communicate branches (idea: telegram bot)
  • A better way to communicate jersey number assignments (idea: telegram bot as well)

• During Game

  • Keep Track of robot substitutions
  • Keep track of code and parameter changes

• Post game

  • Common game branch naming scheme
  • Upload all replay data to a fixed location
  • Ideally the replay data should be self-describing, i.e. some reference to the code (currently we have the folder names for that)
  • probably out of scope for deployer tooling
    • automatic hulk_imagine application to all uploaded replay data for Long-term data preservation
    • some sort of web-based browser for replay data, allowing to quickly replay specific players from different matches

[schmidma]

Agreeing to ole, adding some additional ideas (also beyond the deployer role):

• Pregame
  • communicating the status (not continuously asking "what is the current state, are you deploying, etc")
  • tooling in this phase can also be designing a process or communication strategies
• During Game
  • central logging, all HULKs can add ideas, or observations to the log; probably requires a special agreed on format (e.g. timestamp, robot, kind of observation, etc...)
  • using the team communication monitor logs? (the only advantage: may be showing opponent robots)
• Post Game
  • status of postgame progress
  • idea on code reference: shipping a source distribution with an upload

[oleflb]

Before Game

Branch Communication

@schmidma has to work without internet (maybe problematic with telegram bot)
@schluis conflicts happen during merging, we cannot just ignore them?
@schmidma we need consistent formatting for config files (makes conflicts much rarer)
@schmidma overlays for parameter files (similar to locations)
@pejotejo to overcome internet issues, bring own hardware to the event where we can host stuff

JerseyNumber Assignment

@MaikRe new jersey numbers makes things harder, have to coordinate with new jersey number scheme
@schmidma hardware solution for jersey numbers (NFC tags maybe?)
@oleflb is sceptic about hardware solutions, just solving the issue that deployer does not have to check everything thrice is enough
@schmidma display on charging box

During Game

@schmidma source distribution on nao
@schmidma commits are error prone
@schmidma log file for deployer commands
@schmidma aliveness shows diff (player number changes)
@oleflb write framework start time into replay file

Postgame

@oleflb event data pipeline
@Vivituhh doesnt want to download replay files on her laptop
@pejotejo central server at event
@schmidma this can be done in the router server
@oleflb is a fan of remote replay hosting
@larskna replay still doesnt work on ARM

@julianschuler CI is slow maybe add visualization
@schmidma archive teamcomm logs (script which listens)

• @oleflb maybe hardware solution (small pi with some buttons and display)
• @schmidma job for logführer (has to upload archived logs)
  @schmidma dashboard has to be simple (look at small size league dashboard)

Prios:

1. deployer.toml
2. source distribution (tarred)
3. config files to other format (probably toml, other formats possible, have to support serde)

[schmidma]

Just realized, that toml does not have a representation of null... this might be a problem 🙈