HTCondor Adapater also supports account info.

[fodinabor]

Add HTCondor as an option for the account_cache.
We do want users to be able to select which account (quota group in HTCondor), they want to use for a OOD job.
For that, we need to communicate this information outward.
For Slurm the account_cache is used for this - we should also just allow HTCondor as an accounts provider.

This change has been deployed locally (on an older master) for a while (since July?).
I hope nothing has changed about the meaning of this since then? :)
I'd love to get this upstream as well, to enable other people to use the full functionality of the HTCondor backend (and to reduce the complexity of our setup :))

[johrstrom]

I hope nothing has changed about the meaning of this since then? :)

Something has/will change slightly. Slurm adapters used to return all accounts for all clusters. This is changing. Slurm adapters will start to return only accounts for the cluster the adapter is associated with. This change is currently in progress.

I see the htcondor already supports the accounts so API so on the surface I'm good with this, though I would ask if you can confirm it's implementation only returns accounts for the cluster that the adapter is associated with.

[fodinabor]

I see the htcondor already supports the accounts so API so on the surface I'm good with this, though I would ask if you can confirm it's implementation only returns accounts for the cluster that the adapter is associated with.

As to this question: the HTCondor adapter reads the account mapping from a user/group mapping file that HTCondor uses - the file (path) has to be specified per cluster and it will ask the corresponding cluster's submit host for the file, if it has to:
https://github.com/OSC/ood_core/blob/f6b30a95d3f42c78ef070f83116acbad0d21e731/lib/ood_core/job/adapters/htcondor.rb#L223

[johrstrom]

Thanks for the patch!