| adamwill | |
| jskladan |
Added systemd services for dockerized OpenQA (as an alternative
for OpenQA's official systemd services), added systemd service for trigger
and created timer for trigger (to replace cron).
There is a service file for run-nightly.sh and for timers rawhide and nightly
also, but since we don't have run-nightly.sh in repository, I don't mention
them in README.
try to set up systemd services according to README and observe that
trigger starts as it should.
| No Linters Available |
| No Unit Test Coverage |
| Buildable 152 | |
| Build 152: arc lint + arc unit |
I'm fine with the idea in principle, but the timers in this diff seem messed up. There's a trigger-branched-report.timer which runs "Rawhide", and a trigger-rawhide-report.timer which runs "current". The trigger-current.timer actually does what it says, but doesn't do it at the right frequency: it should run very frequently, not daily (via cron we currently run it every hour, we might even want to do it every 30 or 15 mins).
While we're doing this, I'd say we should do it properly: check the run-nightly script into git and rig up a simple Makefile or setup.py for the tools which installs them in a sensible layout. Then we don't have to have services referencing homedirs. We should also correct our permissions to be more in line with upstream's and run the trigger jobs as root (or invent some other privileged user for the purpose, but that seems excessive), not geekotest: the upstream design is that geekotest is the user the web UI runs under, and consequently it should have very restricted privileges. We're currently giving geekotest way too much power for a user running a web service. It's a bit academic while our instance is behind the firewall, but we should do this properly.
D544 is my diff which modularizes openqa_trigger and adds a setup.py, I'd suggest doing this on top of that and having setup.py install the services and timers?
Yeah, it got messed up, supposedly during merge of Docker and "normal" variants of service files (I had them in separate folders before).
The trigger-current.timer actually does what it says, but doesn't do it at the right frequency: it should run very frequently, not daily (via cron we currently run it every hour, we might even want to do it every 30 or 15 mins).
My bad, I wrongly interpreted current cron job in BOS :-).
Ok, so I have updated it to D547. I have removed geekotest usage and corrected path to point to /usr/bin. It will require copying run-nightly.sh into /usr/bin from withing setup.py though.
Awesome, thanks! I'll revise D547 today. I was also expecting to install the systemd services from setup.py; would this also work for the Docker case? Can you have timers inside a Docker...thing?
This looks fine to me now, we just have to decide whether to make the install of run-nightly.sh part of this, part of D547, or its own thing.
Nope, because there is no init system in Docker :-). But our current scheme is running OpenQA in docker (with openqa-data, openqa-webui and openqa-worker), but having openqa_trigger (or whatsitsname) installed normally on the system - because openqa_trigger uses HTTP to communicate with OpenQA and it doesn't care whether it's installed on the system or runs in docker, so current setup is OK for both cases.
So yeah, this looks fine to me. It might make sense to check in run-nightly.sh as part of this and document installing it manually, but it's OK if you'd rather do that separately.