Project

General

Profile

Feature #7344

jobsub_rm/hold/release mass remove functionality

Added by Nathan Mayer about 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
Start date:
11/19/2014
Due date:
% Done:

0%

Estimated time:
Stakeholders:
Duration:

Description

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.

History

#1 Updated by Parag Mhashilkar about 5 years ago

  • Assignee set to Parag Mhashilkar
  • Target version set to v1.1.1

#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.

#3 Updated by Matthew Toups almost 5 years ago

I also need the jobsub_rm <user> functionality for my work.

#4 Updated by Parag Mhashilkar almost 5 years ago

Also requested by Sea Quest RITM0165788

#5 Updated by Parag Mhashilkar almost 5 years ago

  • Target version changed from v1.1.1 to v1.1.2

#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.

#8 Updated by Christopher Backhouse almost 5 years ago

Formatting got mangled:

jobsub_q --user=$USER | grep '@' | sed s/gov.*/gov/`; do echo $k; jobsub_rm --jobid=$k; done

#9 Updated by Parag Mhashilkar over 4 years ago

  • Target version changed from v1.1.2 to v1.1.3

#10 Updated by Parag Mhashilkar over 4 years ago

  • Subject changed from jobsub_rm mass remove functionality to jobsub_rm/hold/release mass remove functionality

#11 Updated by Parag Mhashilkar over 4 years ago

  • Target version changed from v1.1.3 to v1.1.4

#12 Updated by Parag Mhashilkar over 4 years ago

  • Assignee changed from Parag Mhashilkar to Dennis Box

#13 Updated by Dennis Box over 4 years ago

  • Target version changed from v1.1.4 to v1.1.5

#14 Updated by Joe Boyd over 4 years ago

Another user in INC000000565328 is expecting to be able to remove all the jobs in a cluster.

#15 Updated by Arthur Kreymer over 4 years ago

As noted in INC000000565328 2015/06/30
a full cluster can be manipulated with a single command,
by omitting the process from the jobid :

jobsub_rm --jobid=

Missing only the full-user list and other advanced options.

#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

Hi Philip,

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.

#18 Updated by Christopher Backhouse over 4 years ago

Can we see the list of jobsub priorities? I suspect the experiments would prefer to reorder that list.

#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.

#21 Updated by Dennis Box over 4 years ago

  • Priority changed from Normal to High

#22 Updated by Dennis Box over 4 years ago

  • Status changed from New to Feedback
  • Assignee changed from Dennis Box to Parag Mhashilkar

please see branch 7344

#23 Updated by Parag Mhashilkar over 4 years ago

  • Assignee changed from Parag Mhashilkar to Dennis Box

We talked about this. In summary we should use a different api rather than overloading the jobs api.

#24 Updated by Dennis Box over 4 years ago

  • Status changed from Feedback to Closed


Also available in: Atom PDF