Let’s take a step back. Batch is trying to replace a range of third-party schedulers. The most common ones are: Slurm, Sun Grid Engine (now Univa Grid Engine) and HTCondor. I’ve used these at various companies, sometimes on the cloud and sometimes not. They’re all really good tools and they’re all done very well. Batch is trying to replicate their success.
One key feature in all of these is user attribution for jobs. That’s not to say that every part of batch needs to be fully segmented by user. Maybe the CLI would only contain that information as a column, but it wouldn’t be centered around that.
In a research group, you have many different users chaotically launching and deleting their own jobs within a single project. They need some way to co-exist within the project. That could mean allowing a single project to have multiple batch instances running, one per user. It could also mean giving the administrators the ability to deny control of batch jobs outside of their own username.
My best guess is allowing a project to have multiple instances of batch would be a good solution to this. For many GCP services you can have multiple instances (databases, virtual machines, etc). In batch, that’s not the case.
LinkedIn
Twitter
