PoC - Generic Tasks implementation #3204
Conversation
In case you have different GLIBC versions inside and outside of the chroot we would get errors. As dynamic linking saves a bit of space we shouldn't always do this but as we only do this for compare scripts and not the submissions this is quite a small diskoverhead.
In a future commit we'll display those on the judgehost pages as a simple way to run some shell commands on judgehosts.
Maybe we should run generic tasks with a dedicated user, that way we can limit the allowed commands or even allow commands which need sudo. Something like this: https://at.magma-soft.at/sw/blog/posts/The_Only_Way_For_SSH_Forced_Commands/ or this: https://stackoverflow.com/a/50067008
I've now limited it to admins, but I wonder if this is something which any jury member should be able to do.
We can either pass the externalid or the id of the immutableexecutable. For now I went with the externalid as the immutable makes that it can be cached and we can use the wrong URL bij accident. The advantage of using the immutable is that we get some extra info about which versions were ran via the log. The same thing can be extracted from the judgetask table.
This does not return to the page which indicated it when you use the single judgehost task and are at the judgehosts page.
For some of those tasks it makes sense to get a diff between all judgehosts to see how different those are.
|
I think something like this in general can be useful, didn't look at the code yet. We need to think through the current UI/UX though:
Perhaps we can find a whiteboard at KIT next week and talk through how it should look like? |
|
Ui is indeed just a mockup, if we want it the next step was displaying the result with a good diff viewer. |
I think it needs a proper bootstrap table, but this was just for the mockup.
I think this is almost instant so not sure if that is really needed.
There is no page yet, if we like this I think I want it with a diff viewer as this makes most sense for scripts to compare output over different judgehosts (a startup script for example, or something which is ran before judgement starts) and to give a possibility to mark some output as desired and disable the judgehost when it gets another output.
It works the same as on the overview page, probably having the judgehost link as link to the script is better and have a button to trigger the run.
But having that empty is also strange IMO.
I would have liked to get parts merged before NWERC to test with it at NWERC but lets discuss onsite. |
2 participants
This should be a minimal version to allow to run specific general tasks on the judgehosts. When we agree on this format the next step is to use such a script when a judgehosts registers and use that output to compare against other judgehosts and disable it if it differs from the others. That way someone can have a notion of how similar judgehosts should be without having to check manual.
I've tried to explain my reasoning in the commits to make reviewing and changes easier, this is probably not how we want it yet but a good start to discuss how this should work. So basically 2 questions:
There are some empty commits for remarks I already had myself but left unanswered to not waste time on this route if we don't want it.