get all available accounts for a user from the scheduler

[johrstrom]

Fixes upstream ood issue below. The idea here is that the scheduler (Slurm in this case) knows all the valid accounts that a user is able to use. So instead of pulling accounts from Unix file systems, we can query the scheduler itself. A Unix group may or may not be a valid account as the account can suspended/closed due to budgets but the Unix group still exists.

OSC/ondemand#1970

┆Issue is synchronized with this Asana task by Unito

[treydock]

See inline comments for requested changes

[Oglopf]

Looks good.

[johrstrom]

I don't believe this will work as is. We're likely going to need at least qos associated with the account. So passing just strings back is not likely enough.

With some sites, partition will show up in this output. On other sites, I believe we'll need another query to stitch together with this data.

sacctmgr show association 'format=account,partition,qos%100,' where "user=$(whoami)"

[treydock]

If you use --parsable or --parsable2 flags you don't need format length like %100. Just FYI as that would simplify the logic.

As far as whether this works, I think it's a good starting place. Having a list of available accounts irregardless of partition is good. However I don't think you will need to query QOS since an association in the database is either "cluster + account + user" or "cluster + account + user + partition". The QOS is an attribute on the association. I think it's a bridge too far for OOD to try and work out how a QOS is used because a QOS can be used to limit resources or just do things like set priority or preemption. A QOS is not typically how you grant someone access to resources, that's usually done through the association in one of the two defining ways previously mentioned.

[johrstrom]

Thanks for the reivew, I've added a bit. Namely the AccountInfo class so it can hold extra information for all the use cases we need.

Check out this Utah sacctmgr output. Some accounts only exists on 1 cluster (smithp-guest on ahs or dtn on notchpeak). So for this to be useful every account has to be sort of cluster aware so that upper layers can hide/show options as needed.

[u6031686@kingspeak1:~]$ sacctmgr -np show user withassoc format=account,qos,cluster where user=$(whoami)
smithp-guest|ash-guest,ash-guest-res|ash|
chpcservice|kingspeak|kingspeak|
owner-guest|kingspeak-guest|kingspeak|
chpcservice|lonepeak|lonepeak|
owner-guest|lonepeak-guest|lonepeak|
dtn|notchpeak-dtn|notchpeak|
notchpeak-shared-short|notchpeak-shared-short|notchpeak|
chpcservice|notchpeak-freecycle|notchpeak|
owner-guest|notchpeak-guest|notchpeak|

I'm quite sure this is not enough as the upper layers (OOD) is going to have to stitch a lot of information together. But as an initial luanch maybe it can just pull adapter.accounts.map(&:to_s) initially.

In any case, I know for sure these are going to be more complex than just a string, so we may as well start with objects.

[johrstrom]

Unfortunately I can't seem to get sacctmgr to query per cluster, which is going to be troublesome for upper layers as each adapter object is meant to represent 1 cluster, but here we are returning information for all clusters.