Clarify caveats with custom job hooks after 6cf76ae8b #3622
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3622 +/- ##
=======================================
Coverage 95.97% 95.97%
=======================================
Files 367 367
Lines 31926 31926
=======================================
Hits 30641 30641
Misses 1285 1285
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
I'm sure you can read the config from Minion jobs. That's what we do in other Minion jobs as well. It looks like it just didn't work because you didn't extend OpenQA::Setup::read_config to actually read the section/keys. So at lest the commit message seems room.
|
Yes, you can absolutely read the config from Minion jobs. |
|
yes, but consider the example of running the GRU service elsewhere, e.g. in a separate container. Could it be we never read the config in GRU so far and it's also something that we do not want? |
|
We currently read the config in GRU and actually rely on that already. If one runs GRU in a different container the config should be present in that container as well. The same counts for any other spin-off services like the websocket server, live handler and so on. Read my last comment to understand why the config from your last PR had no effect. It had nothing to do with GRU. |
|
Yes, yes, I got that :) |
okurz
force-pushed
the
fix/hooks
branch
3 times, most recently
from
d26155d
to
f3c8bab
Compare
|
updated:
|
okurz
force-pushed
the
fix/hooks
branch
2 times, most recently
from
c469d65
to
6147410
Compare
|
This pull request is now in conflicts. Could you fix it? 🙏 |
This commit clarifies some further caveats in the documentation, e.g. apparmor rules as well as where the overall status can be found. Related progress issue: https://progress.opensuse.org/issues/80736
As it turned out reading job hook settings from configuration does not work unless at least the section is explicitly mentioned in lib/OpenQA/Setup. I only mention the section header and not any default hook values as that would prevent reading any other, dynamically defined hook config key. Also tested the reading of config of dynamically defined config parameters manually with ``` sudo -u geekotest perl -d script/openqa gru -m production run --reset-locks ``` Related progress issue: https://progress.opensuse.org/issues/80736
|
I recorded the failure of t/full-stack.t in https://progress.opensuse.org/issues/80800 and rebased to fix the conflict |
As it turned out reading job hook settings from configuration does not
work for a separate GRU service. Likely because this service never reads
the config file /etc/openqa/openqa.ini . Hence it is questionable if we
want to support reading from the generic config file considering that
the GRU service is standalone and can be run in a separate environment,
e.g. a separate host or container.
This commit removes the ineffective code for reading the config settings
and also clarifies some further caveats in the documentation, e.g.
apparmor rules as well as where the overall status can be found.
Related progress issue: https://progress.opensuse.org/issues/80736