action #130378
Updated by okurz 11 months ago
## Motivation
In #118636 we decided that we will just use https://gitlab.suse.de/openqa/salt-states-openqa to control all machines that are not yet controlled by a remote management framework yet. For some machines we already have specific salt repositories, e.g. https://gitlab.suse.de/qa-sle/backup-server-salt . We should try to use [salt formulas](https://docs.saltproject.io/en/latest/topics/development/conventions/formulas.html) to integrate those repositories into our central infrastructure
## Acceptance criteria
* **AC1:** Changes to https://gitlab.suse.de/qa-sle/backup-server-salt as well as https://gitlab.suse.de/openqa/salt-states-openqa are applied automatically to backup.qa.suse.de
* **AC2:** The solution to integrate https://gitlab.suse.de/qa-sle/backup-server-salt is salted itself
* **AC3:** We know how to integrate other separate salt repositories
## Suggestions
* Read https://docs.saltproject.io/en/latest/topics/development/conventions/formulas.html
* Try to reference https://gitlab.suse.de/qa-sle/backup-server-salt as a salt formula within https://gitlab.suse.de/openqa/salt-states-openqa but within salt itself but also at best coming from https://gitlab.suse.de/openqa/salt-pillars-openqa/ so that SUSE internal repos are only referenced internally
* If the solution is not obvious then document how it's done, e.g. in gitlab.suse.de/openqa/salt-states-openqa/
* Ensure https://gitlab.suse.de/qa-sle/backup-server-salt explains that the repo is used from within gitlab.suse.de/openqa/salt-states-openqa/
* Adapt or remove parts of the repo, e.g. adapt the gitlab CI integration to use the formula relying on the other repo (or just remove?)
* If all else fails then just put everything from https://gitlab.suse.de/qa-sle/backup-server-salt to https://gitlab.suse.de/openqa/salt-states-openqa