You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -913,6 +915,95 @@ Jupyter system app in the menu along with your sandbox development app.
913
915
914
916

915
917
918
+
## Dynamic Batch Connect Fields
919
+
920
+
Since 2.0 sites can enable dynamic batch connect fields through setting the `OOD_BC_DYNAMIC_JS` environment
921
+
variable. This has already been done within these containers.
922
+
923
+
```text
924
+
# /etc/ood/config/apps/dashboard/env
925
+
OOD_BC_DYNAMIC_JS=1
926
+
```
927
+
928
+
With this feature - client side javascript can dynamically change the form fields based on user
929
+
choices. Sites only have to add more YAML to a `form.yml` to enable this behaviour. Let's
930
+
see some examples.
931
+
932
+
### Changing min & max values
933
+
934
+
Let's put some rules around the debug queue. We set a static `min` and `max` of 200 and 1000
935
+
respectively. But in this example, we want different min and max values for the debug queue.
936
+
937
+
We can configure this behaviour with these `data-min-` and `data-max-` directives attached
938
+
to a given option. When the `debug` queue is choosen we'll automatically set the min and
939
+
maximum values of the `memory` field.
940
+
941
+
Note that we're also setting the `compute` min and maxes again. This is currently the only way
942
+
to reset back to defaults if there are any.
943
+
944
+
```yaml
945
+
# form.yml, only showing custom_queue for brevity.
946
+
custom_queue:
947
+
widget: "select"
948
+
label: "Partition"
949
+
options:
950
+
- [
951
+
"Compute", "compute",
952
+
data-min-memory: 200, # set the compute queue back to static defaults
953
+
data-max-memory: 1000,
954
+
]
955
+
- [
956
+
"Debug", "debug",
957
+
data-min-memory: 400, # change min & max for debug queue
958
+
data-max-memory: 600,
959
+
]
960
+
```
961
+
962
+

963
+
964
+
### Changing values
965
+
966
+
Let's take this a little further. Now, when we choose `compute` or `debug` queue, let's automatically
967
+
set the Slurm account we want to use. Note we'll need to add `bc_account` back, as it's what we'll be
968
+
setting.
969
+
970
+
We can add the `data-set` directives on the same `custom_queue` form options. When users choose the
971
+
`debug`queue we'll automatically set the account to `staff`. When we choose the `compute` queue we
972
+
will set the `sfoster` account.
973
+
974
+
```yaml
975
+
# form.yml, only showing custom_queue for brevity.
976
+
attributes:
977
+
custom_queue:
978
+
widget: "select"
979
+
label: "Partition"
980
+
options:
981
+
- [
982
+
"Compute", "compute",
983
+
data-min-memory: 200,
984
+
data-max-memory: 1000,
985
+
986
+
data-set-bc-account: 'sfoster' # set the account to sfoster when using compute
987
+
]
988
+
- [
989
+
"Debug", "debug",
990
+
data-min-memory: 400,
991
+
data-max-memory: 600,
992
+
993
+
data-set-bc-account: 'staff' # set the account to staff when using debug
994
+
]
995
+
form:
996
+
- bc_account
997
+
```
998
+
999
+
To use the `sfoster` account you need to run these commands to add the `hpcadmin` user to
1000
+
that account.
1001
+
1002
+
```
1003
+
sudo sacctmgr add user hpcadmin account=sfoster
1004
+
sudo sacctmgr modify user where user=hpcadmin set defaultaccount=staff
0 commit comments