We are ingesting SLURM account information at each user’s nginx instance start via the /etc/ood/config/apps/dashboard/initializers/ood.rb (our SLURM account/partition/qos mapping is complicated so we can’t use the dynamic parts that OOD provides). We have been doing this by running customized SLURM commands and ingesting the command output into a Ruby object.
Now our developers have a web portal in place that stores the SLURM account information, and would like to do this via an HTTP request to this web portal so we don’t have to call the SLURM commands. Is there a recommended way how to do this?
Sounds like you’d want to write your own form.js and use the fetch API to query your service.
One of these days I’m going to log back into my account on Utah systems and get this sorted for you. account/partition/qos mapping was meant for sites like yours (OSC doesn’t use these things on the client side) but I’m just struggling to find time to get it over the last mile.
Alternatively if I never get around to logging back into Utah - if you could provide test data to test against and a few descriptions of test cases I could work off of that and get this going.
Lastly if you have developers working on web portals - you can just implement it yourself and push it upstream to us.
I’m very eager to get this done for you all (so you don’t have to build web apps and javascrtipt and so on), I just need a combination of time and test data/use cases.
Thanks Jeff, I think we’ll stick to our current model (reading the cluster:account:partition:qos) from a file that we generate upon each user’s OOD login and feed that to the customized form.yml.erb and form.js.
But, I will put it to my list to try the dynamic accounts on our test cluster once we have this recent change (which added the qos) as I think that is mapping to what you have developed closer to what we had till now. I’ll give feedback once I do that.