Access to "auto_accounts" data within form

Get Help
1

Hi All! Quick question:

Is there a way to access the list of Slurm accounts that is generated with “auto_accounts” within a form.yml.erb file?

For example, it is easy to get a User’s POSIX groups:

<%
usergroups = User.new.groups.map(&:name).grep(/Grp$/)
%>

What would be the equivalent for Slurm accounts?

Thanks!

2

You can call these internal methods directly in ERB. Here’s how to do it.

<%- 
  extend AccountCache
  raise(StandardError,  dynamic_accounts)
-%>

And I’m just raising the error to see what the return value is (you can see it’s arrays of arrays).

image
image1872×142 15.2 KB

3

Jeff, this worked perfect. Here is a short example of how I used this below:

<%
extend AccountCache
useraccounts = dynamic_accounts
#raise(StandardError,  dynamic_accounts)
contributors = ["contrib1", "contrib2"]
%>
---
attributes:
  accounts:
    label: "Slurm Account"
    widget: "select"
    options:
      <%- useraccounts.each do |g| -%>
      <%- if contributors.include? g.first.downcase -%>
      - [ "<%= g.first.downcase %>", data-set-queues: "ondemand", ]
      <%- else -%>
      - [ "<%= g.first.downcase %>", data-set-queues: "ondemand", ]
      <%- end -%>
      <%- end -%>
    help: |
      The Slurm account to be used for your job submission.
  queues:
    label: "Slurm Partition"
    widget: select
    value: "ondemand"
    options:
      - [ "ondemand" ]
      <%- useraccounts.each do |g| -%>
      <%- if contributors.include? g.first.downcase -%>
      - [ "<%= g.first.downcase.gsub('grp', 'Grp') %>", data-set-accounts: "<%= g.first.downcase %>", ]
      <%- end -%>
      <%- end -%>
    help: |
        - **Default: ondemand** <br>
          1 node with 64/48 cores max. for <=48 hours.
  node_type:
      widget: select
      label: "Node type"
      options:
        - [
            "Any", "any",
            data-max-num-cores: 64,
            data-max-num-gpus: 0,
            data-min-num-gpus: 0,
            data-max-memory: 2250,
            data-option-for-queues-ondemand: true,
            data-option-for-accounts-contrib1: true,
            data-option-for-queues-contrib1: false,
            data-option-for-accounts-contrib2: true,
            data-option-for-queues-contrib2: false,
            data-set-num-gpus: 0,
            data-hide-num-gpus: true,
          ]
        - [
            "contrib1: Node", "contrib1_node",
            data-max-num-cores: 32,
            data-max-num-gpus: 0,
            data-min-num-gpus: 0,
            data-max-memory: 220,
            data-option-for-queues-ondemand: false,
            data-option-for-accounts-contrib1: true,
            data-option-for-queues-contrib1: true,
            data-option-for-accounts-contrib2: false,
            data-option-for-queues-contrib2: false,
            data-set-num-gpus: 0,
            data-hide-num-gpus: true,
          ]
        - [
            "contrib2: Node", "contrib2_node",
            data-max-num-cores: 32,
            data-max-num-gpus: 0,
            data-min-num-gpus: 0,
            data-max-memory: 220,
            data-option-for-queues-ondemand: false,
            data-option-for-accounts-contrib1: false,
            data-option-for-queues-contrib1: false,
            data-option-for-accounts-contrib2: true,
            data-option-for-queues-contrib2: true,
            data-set-num-gpus: 0,
            data-hide-num-gpus: true,
          ]

where we have two contributing groups, each with their own Slurm account, queue, and node. If they just submit with their Slurm account (contrib1) to the general “ondemand” queue, they have access to “Any” node. If they submit with their Slurm account (contrib1) AND Slurm queue (contrib1), they have access to their specific node.

Thanks again,
Sean

1 Like