Differentiate idle status from queued status

fcasson commented 4 years ago

This applies when policies['maximumTimeInQueue'] > 0

If a job is not yet running because it is waiting for resources to become available, it should be a different state from a job which is waiting to to find out if resources are available.

Or more simply, once could just rename the "idle" status to "queuing" or "queued" or "waiting" which is probably more meaningful to users and more or less covers both states.

fcasson commented 4 years ago

Relevant statusReason already exists, so should be possible to build a queued status on this basis

prominence describe 37285 | grep -i status
  "status": "idle",
  "statusReason": "No matching resources",

alahiff commented 4 years ago

Sorry, I should have updated this issue a long time ago. I had made an update to have two queuing states:

idle: initial state, before any deployment attempts have take place
waiting: the job is waiting for resources to become available. The status reason will be No matching resources currently available in this case.

Jobs which are impossible to run (e.g. too many CPUs requested) will fail quickly with No matching resources as the reason as it doesn't make sense for them to remain queued.

Regarding idle vs queued, I guess I picked idle because I'd gotten used to HTCondor, and it uses the term idle for jobs which are not running yet (whereas PBS uses queued and SLURM uses pending).

I'm starting to think that having so many similar states (idle, deploying and waiting) is too confusing, it might be best to have a single status for all jobs not yet running and the status reason can be used to find out what's going on.

prominence-eosc / prominence

Differentiate idle status from queued status #120