Jakub Beránek
Jakub Beránek
1) This is definitely a valid use case and we intend to support it. Currently, this can be achieved in a semi-manual way. You can assign resources to specific workers...
Hi! It's definitely in our (longer term) plan. Server and worker resiliency is a quite complicated topic that affects the design of a lot of areas of a task runtime...
Currently, there is no persistence in HQ. If an allocation queue is removed, its data will be lost, and you have to recreate all allocation queues after you (re)start the...
You can get the following logs currently: 1) Task logs (data outputted by executables launched by a task) - these are written to `--stdout`/`--stderr` paths specified in `hq submit`. 2)...
In theory, you can get this information, if you enable really verbose logging on server/worker and then parse it out of it, but that's not ideal. Currently, HQ is primarily...
Killing the server processes on login nodes is a valid concern indeed. The server will only begin to be a perf. bottleneck if there are either a lot of tasks...
The concept looks nice so far. I wonder if we should first add reading log events from a file? It will require changes that will also be relevant for the...
This is probably a job for Tako?
I have been playing with this for a bit and it seems to be quite tricky. We'll probably do some best effort mechanism using process groups and setsid to kill...
Fixed by https://github.com/It4innovations/hyperqueue/pull/514.