jobsub_rm/hold/release mass remove functionality
jobsub_rm needs the ability to remove all of the users jobs like condor_rm <user>. It would also be nice if it had a cluster remove option, instead of just a single comma separated list of jobids. This makes it very hard for individual users to mass remove jobs.
#2 Updated by Dominick Rocco about 5 years ago
There are actually a lot of things that are supported by condor_rm which are not possible with jobsub_rm. The possibilities of the --constraint argument were almost endless, although the syntax and possible constraints was never esspeically well documented. Adding a --constraint flag to jobsub_rm would be an acceptable solution. An even nicer solution would be to wrap up some of the common use cases into flags for jobsub_rm. For instance, it would be nice if you could have a --held flag to remove held jobs, or use something like "--status H".
As an added bonus, it would be great if anything that worked for jobsub_rm also worked for jobsub_q.
#6 Updated by Philip Rodrigues almost 5 years ago
This needs to be a much higher priority: this functionality is part of a normal workflow for all users, and without it, using jobsub_client is painful. Additionally, we're now being notified of held jobs by the production operators, and being asked to remove them, which is much harder without this functionality.
#7 Updated by Christopher Backhouse almost 5 years ago
The best one can do right now is something like
for k in `jobsub_q --user=$USER | grep '' | sed s/gov.*/gov/`; do echo $k; jobsub_rm --jobid=$k; done@ which is a complete pain to figure out and type in, and extremely slow to execute. We've had multiple users ask this question, and this is all we can tell them.
#16 Updated by Philip Rodrigues over 4 years ago
Please implement this feature. I am currently wasting my time and my collaborators' time trying to find the exact bash incantation to do this. This was functionality that existed in the old system, which is needed by all users, and is essentially straightforward (and certainly more straightforward than having everyone at the lab fight with bash every time they need to do this). I really don't understand why this has not been done yet, and it's extremely frustrating.
#17 Updated by Parag Mhashilkar over 4 years ago
Issues are addressed based on their relative priorities wrt to other tasks that are on our plate. Issues like this that have alternate means to address the problem are usually lower than issues that do not have alternate solutions. Said that we understand the need for this feature and will be tackled appropriately in one of the future versions.
#19 Updated by Philip Rodrigues over 4 years ago
The workaround is problematic for a few reasons. For one thing, it depends on screen-scraping the output of jobsub_q, so it's going to break whenever you change that output. For another, it uses a complex string of bash commands that most of my users are not able to debug.
The common result of this workaround (it happened just yesterday) is that a user asks me how to do this, I spend some time digging around in my email to find the command, send it to them (praying that no one's email client mangles it and that they copy-paste it just so), find it didn't work because I got the wrong version or something changed, have to go back and forth with various guesses until we find an incantation that works. This results in me and other minerva analyzers spending a lot of time that we really shouldn't have to doing something that should be simple, which hurts our ability to do physics.
#20 Updated by Parag Mhashilkar over 4 years ago
Christopher Backhouse wrote:
Can we see the list of jobsub priorities? I suspect the experiments would prefer to reorder that list.
For the list of tickets associated with each release, you can look at the custom queries on the right side column of this page.