Ah! My mistake. I can’t confirm or deny the existence of those as that’s not what I was looking for when I had that stuff in front of me. What you /could/ do is to alias the command for your users, not unlike what is often done in the /etc/skel files for “ls” to add colors or whatever else. Maybe less convenient, but a possible workaround.
> On Feb 2, 2016, at 1:46 PM, Timothy Gray <[email protected]> wrote: > > I don't see what you're talking about, Markus' email shows them passing the > format string as a part of their custom script, what I am suggesting is > environment variables that will effect the default output of sacctmgr show > qos (and other entities) like SQUEUE_FORMAT and SINFO_FORMAT. > > I haven't read the documentation top to bottom, but from perusing the > sections about list/show and searching for the words > variable/environment/format I haven't found anything to suggest this exists. > > Thanks, > Tim Gray > ________________________________________ > From: Novosielski, Ryan <[email protected]> > Sent: Monday, February 1, 2016 6:00 PM > To: slurm-dev > Subject: [slurm-dev] Re: Advice on presenting QOS to users > > Markus’ earlier e-mail shows you how to do same with sacctmgr. It’s in the > documentation as well: > > http://slurm.schedmd.com/sacctmgr.html > >> On Feb 1, 2016, at 12:06 PM, Timothy Gray <[email protected]> wrote: >> >> Paul~ >> >> That's great, I didn't see them in the documentation so I didn't think they >> were implemented, thanks for letting me know!. This does still leave the >> question of whether the same could be implemented for sacctmgr (or if it >> already has, I may dive into the code a bit later). I could see there being >> one format env variable for each entity. Does anyone think that's a good >> idea? >> >> Markus~ >> >> Thanks, I really like this idea, this is probably what we will end up going >> with; but I do still wish there were a way to clean up the output of >> sacctmgr without having to type out or copy/paste long format strings. Even >> as the admin I find it quite tedious. >> >> Trey~ >> >> We've decided to stay away from the torque wrappers mostly because we don't >> think we'd ever be able to abandon them with the way our user base hangs >> onto things and pass around custom environments to new users under the radar. >> >> Thanks, >> Tim Gray >> ________________________________________ >> From: Markus Stöhr <[email protected]> >> Sent: Friday, January 29, 2016 6:38 AM >> To: slurm-dev >> Subject: [slurm-dev] Re: Advice on presenting QOS to users >> >> Dear Tim, >> >> we are printing this information at login: >> >> cat /etc/profile.d/z-slurminfo.sh: >> >> shopt -q interactive_comments login_shell >> if [ $? == 0 ]; then >> #echo this is a login shell >> echo "===" >> echo "Your jobs can run with the following account(s) and >> quality of service (QOS):" >> echo >> sacctmgr show user `id -u` withassoc >> format=user,defaultaccount,account,qos%40s,defaultqos%20s >> else >> #echo non-interactive shell >> : >> fi >> >> For further details, users should look up the pages in our wiki. >> >> br >> Markus >> >> >> On 01/28/2016 10:45 PM, Timothy Gray wrote: >>> Hi, >>> >>> I'm working on moving our clusters from torque/maui to slurm and we have >>> decided to use QOS to replace the notion of queues that we had in PBS; >>> however, we are unsure about the best way to reveal available QOS to >>> users of the cluster. We are trying to be as user friendly as possible >>> since we have many different skill levels amongst our user base, so we'd >>> prefer to have a command that will show a user just the relevant >>> information (things we've set) and allow them to view other options if >>> they want to, but by default sacctmgr shows everything which is very >>> unreadable. I was thinking about writing an alias or a wrapper script >>> called showqos or sqos that would run sacctmgr with the format options >>> we provide; however I was wondering if anyone has dealt with this >>> already and can share how they deal with this issue at their site? >>> >>> On a related note, I noticed that sacct has an environment variable >>> called SACCT_FORMAT which sets the default formatting string which seems >>> very useful; does anyone know if there's a good reason why there aren't >>> more of these variables for sstat, squeue, sinfo, and the various sacct >>> show/list queries? Is this just on the bottom of a to do list? If so I >>> may be willing to contribute to get this functionality if it just needs >>> doing. >>> >>> Thanks, >>> Tim Gray >>> >>> >> >> >> -- >> ===================================================== >> Dr. Markus Stöhr >> Zentraler Informatikdienst BOKU Wien / TU Wien >> Wiedner Hauptstraße 8-10 >> 1040 Wien >> >> Tel. +43-1-58801-420754 >> Fax +43-1-58801-9420754 >> >> Email: [email protected] >> ===================================================== > > ____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* > || \\UTGERS |---------------------*O*--------------------- > ||_// Biomedical | Ryan Novosielski - Senior Technologist > || \\ and Health | [email protected] - 973/972.0922 (2x0922) > || \\ Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark > `' > ____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS |---------------------*O*--------------------- ||_// Biomedical | Ryan Novosielski - Senior Technologist || \\ and Health | [email protected] - 973/972.0922 (2x0922) || \\ Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark `'
signature.asc
Description: Message signed with OpenPGP using GPGMail
