Sacctmgr usage can be a bit tricky. Although there are "user", "account",
etc. entities that can be manipulated with sacctmgr, much of the time
you are dealing with "association" entities. And although sacctmgr will
allow you to view associations, modifying associations is handled by
sacctmgr commands that _look_ like they are modifying the "user", "account",
etc. entity most directly attached to the association.
E.g., your initial command
# sacctmgr add user lsimp...@domain.com Fairshare=1 DefaultAccount="core"
Partition='prod'
does actually two separate things:
1) created an "user" object lsimp...@domain.com with defaultaccount="core"
on cluster=rosalind (presumably that is the default/only cluster)
2) created an "association" object for (user=lsimp...@domain.com, account=core,
partition=prod,
cluster=rosalind)
When you then try
# sacctmgr mod user lsimp...@domain.com set DefaultAccount="rcf"
it complains because there is no association for lsimp...@domain.com with
account rcf.
Short of the deletion/recreation approach you took (which might very well have
been
the "most efficient" approach in this case anyway), you could have done:
# sacctmgr add user user=lsimp...@domain.com partition=prod account=rcf
This will create the association for lsimpson and rcf
Yes --- one uses "add user" to add an association for an existing user.
Then
#sacctmgr modify user where user=lsimp...@domain.com set defaultaccount="rcf"
This will change the defaultaccount from core to rcf
NOTE: at this point in my scenario, lsimpson still has access to the "core"
account,
it just is not his default account. To remove his access to the "core" account,
one would do, i.e. to remove the association between user=lsimp...@domain.com
and
the account=core on partition=prod, one would use
# sacctmgr remove user where user=lsimp...@domain.com cluster=rosalind
partition=prod account=core
Yes --- one uses "remove user" to remove an association for an user.
By including the account=core, we _only_ remove the user's associations with
the specified
account. If account= was omitted, then all the user's assocations in specified
cluster,
partition are removed. And if only user= is specified, it deletes the user and
ALL of his
associations.
But you are correct, the usage of sacctmgr is sort of counter-intuitive.
On Sun, 17 Jul 2016, Lachlan Musicman wrote:
As a follow up, I'm obviously still confused about how sacctmgr works. See here
- I add a user, and realise I've set their Default Account incorrectly.
So I try to modify it and then I realise it's just easier to delete the user
and start again:
[root@vmpr-res-head-node ~]# sacctmgr add user lsimp...@domain.com Fairshare=1
DefaultAccount="core" Partition='prod'
Adding User(s)
lsimp...@domain.com
Settings =
Default Account = core
Associations =
U = lsimpson@ A = core C = rosalind P = prod
Non Default Settings
Fairshare = 1
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y
[root@vmpr-res-head-node ~]# sacctmgr mod user lsimp...@domain.com set
DefaultAccount="rcf"
Can't modify because these users aren't associated with new default account
'rcf'...
U = lsimp...@domain.com C = rosalind
[root@vmpr-res-head-node ~]# sacctmgr remove user lsimp...@domain.com
Deleting users...
lsimp...@domain.com
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y
[root@vmpr-res-head-node ~]# sacctmgr add user lsimp...@domain.com Fairshare=1
DefaultAccount="rcf" Partition='prod'
Adding User(s)
lsimp...@domain.com
Settings =
Default Account = rcf
Associations =
U = lsimpson@ A = rcf C = rosalind P = prod
Non Default Settings
Fairshare = 1
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y
Is that expected behaviour for reasons I haven't read yet, or am I just
thinking about sacctmgr all wrong?
cheers
L.
------
The most dangerous phrase in the language is, "We've always done it this way."
- Grace Hopper
On 18 July 2016 at 11:21, Lachlan Musicman <data...@gmail.com> wrote:
Hola,
Because I built the cluster on the fly, I named it after my partner. The boss
didn't like this, so we wanted to change the name. (to rosalind for Rosalind
Franklin).
I took a dump of sacctmgr:
sacctmgr dump fiona File=/root/fiona_cluster.cfg
and took a look inside. I didn't read the entire man page because I'm impatient and I saw
the "dump/load" combo and figured it would do what it said on the tin.
I edited the dump file, replacing the cluster name with the new one, renamed
the file and reloaded the cfg file:
sacctmgr load rosalind_cluster.cfg
Didn't work.
First error was that QOS didn't exist?
Cluster - 'rosalind':Fairshare=1:QOS='normal'
Second error was that the partitions didn't exist? Obviously they did - the
only thing that had changed was the cluster name (in the conf, slurmctl and
slurmd had restarted fine across all
nodes).
In particular it was the format of the user lines:
User - 'test_user':Partition='bcl2fastq':DefaultAccount='dev':Fairshare=1
User - 'test_user':Partition='debug':DefaultAccount='dev':Fairshare=1
The Partition section.
I can only surmise that:
- I did something wrong*
- there's an error in the dump/load workflow
I have added all users and associations back by hand - tedious but at least I
could complete it without error.
* note that I recognise I did do something wrong by not reading the man file
thoroughly end to end and missing the line "Cluster= - specify a different name
for the cluster than that which is
in the file."
Having said that, I feel that I must be missing something else/have done something else wrong.
AFAICT those users are showing "Associations" rather than users (hence the
"Partition" part).
I've posted about this here before.
I was using the syntax
sacctmgr add user manfred DefaultAccount=dev Fairshare=x
but then couldn't work out how to mod the user to define a Partition. Of course
the reason this didn't work is because users don't have Partitions -
Associations have Users, Partitions,
Accounts and Clusters. But to add those I was using this (confusing) syntax:
sacctmgr add user manfred DefaultAccount=dev Fairshare=x Partition=dev
Anyway, despite my own failings (numerous), I feel that either dump/load isn't
working as one would expect it to work; or that the docs aren't clear enough
with regard to adding a user and
adding an association.
Cheers
L.
------
The most dangerous phrase in the language is, "We've always done it this way."
- Grace Hopper
Tom Payerle
IT-ETI-EUS paye...@umd.edu
4254 Stadium Dr (301) 405-6135
University of Maryland
College Park, MD 20742-4111
