Hide data elements based on cluster selection with -cluster: "*"

Get Help
1

Hi,

I am trying to dynamically change the data elements of an app form based on the selection of the cluster.

I know it is possible to change the cluster attribute in each of the apps, list all the clusters in it and use the dynamic form --data-hide options. However, I was wondering if similar behavior can be achieved while using the wildcard -cluster: "*" so that listing the clusters in each of the files is not necessary.

A slightly cleaner approach might be by making a yml.erb file containing the cluster attribute and placing <%= ERB.new(File.read(path/to/_cluster_attribute.yml.erb”), eoutvar: “@cluster”).result(binding) %> in each of the app forms.

Is there a solution that works with "*"? Are there other/better solutions?

To clarify, the behaviour I want to reproduce is the following:

#form.yml.erb
attributes:
  cluster:
    widget: "select"
    options:
      - [
          "cluster1", "cluster1",
          data-hide-global-field2: true,
        ]
      - [
          "cluster2", "cluster2",
          data-hide-global-field1: true,
        ]

form:
 - cluster
 - auto_queues
 - global_field1
 - global_field2
2

Hi and welcome!

If I understand the issue you have two global form items that you want to toggle depending on cluster, but having to define the cluster options to include the data-hide directives adds a lot of bulk to your forms.

The most straightforward approach would be to use option-for and exclusive-option-for directives instead, assuming that your two global items can be reasonably converted into select widgets. That is, you would make global1 and global2 into a single large select with both sets of options, and add data-option-for-cluster: clusterX directives to each option so that the set of options completely changes when a new cluster is selected. That would allow you to use the cluster: “*” item at the top of your form while keeping the behavior.

I think what you are looking for with the ERB approach is Configuring cluster in submit.yml, where you can hide the cluster option for the user and then set it based on which options were selected. So you could toggle the visibility of your global items with a global checkbox, and select the right cluster based on which global item was filled out. This would be less verbose than redefining the cluster attribute each time, and might be preferable if your global widgets wouldn’t work as selects.

If neither of those approaches seem like they would work, you can provide more detail about the global widgets and we can find a better solution for the specific case.

3

Hi!

Thanks for the detailed answer. I had not considered swapping the options of a select cluster. I think technically it could work with our use case, but it would be a bit strange to implement it this way. (See below.)

Your second option, although not exactly what I was looking for, is very interesting and could help in toggling these global options while not burdening the user with the selection of the cluster itself.

Our use case right now however is as follows, we have compute clusters with GPUs and a tested cluster with sharded GPUs. Our users can select which cluster they want to run their job on. For the former, we have a number field that allows users to choose the number of GPUs. For the latter cluster, we have sharded GPUs. Users are not allowed to ask for full GPUs rather, they can ask for quarters of a single GPU. This is done via a range field. Hence, ideally, when the latter cluster is selected this range field is shown. Otherwise this number field for selecting whole GPUs.

I think my “slightly cleaner” approach does handle this quite well, but if a built-in approach for handling this exists, it would be preferable.

Kind regards,
Jarne

4

That is an interesting case, and I agree that what you started with is probably easier and cleaner than either of the two options I brought up.

One final option you might consider, which would save you having to redefine the clusters in each form, is to make a global item for cluster selection (likely have to call it something different than cluster) and add your data-hide directives (once). Then in the submit.yml you could use erb to set the cluster to the value of cluster_item, or whatever you end up calling it. So while this would still require updating the cluster_item definition when your clusters change, it keeps everything defined in a single place. The only repeated portion is in your submit.yml for each app, but this should only be about a single line of code, something like <% cluster = cluster_item %>.