Identifying common interactions

[mtwest2718]

Preamble

I grant this is more meta than what @tazend might have originally intended with #202.

From both my reading of the documentation and discussions with users of PySlurm, the existing focus of the library is to support system administrators in their daily tasks. There is support for end-user functionality like job submission in the codebase but it's not prominent in the examples.

So before doing any refactoring of code, I like to think about who we are trying to support and what are their common interactions with the system.

Cluster End-Users

This is a rough list of actions that I can see the average research wanting to be able to do via a Python API.

• Create submit scripts
• Submit jobs
• Query the status of jobs in the queue (running, held, etc)
• Remove jobs from the queue
• Query the cluster partitions about available resources
• Query job history
• Parse job logs

System Administrators

As I am not nearly as familiar with this roll as general cluster user I will have to defer to others. But I believe that many of the daemon query operations done by both groups can benefit from a unified, but modularized, backend framework.

• Query status and settings of daemons
• Start & stop daemons
• Set system configurations
• Manage security settings
• All the stuff end-users can do...

[giovtorres]

The library is meant to have a 1:1 mapping of the Slurm API, and being able to programmatically access the values from scontrol outputs.

With that said, there are some helpful additions that could be added to the library, for example some of the tasks related to submitting jobs like you've mentioned.

What are some of the common tasks you use PySlurm for today?