How to retrieve the current cluster id in an application form?

Get Help
1

I’m looking for help in order to implement the global static list presented in this tutorial
Use a Global Static List — Open OnDemand 4.0.0 documentation

In this example, the cluster name is hardcoded to my_cluster and must correspond to an existing one as highligted in the warning message.

~/ondemand/dev/jupyter/form.yml.erb

<%-
queues = OodAppkit.clusters[:my_cluster].custom_config[:queues]
-%>

Instead of using a hardcoded one, how can I retrieved the current cluster used in the form ? This will allows me to have a generic application form while having different queue definitions per cluster.

2

I’m not sure this can be done without introducing a dropdown for the user to select which cluster to use. As far as I know the form.yml.erb is not cluster-aware — though with OOD, there are often undocumented behaviors, so it’s hard to say definitively.

One possible workaround might involve using an environment variable (e.g., ENV['OOD_CLUSTER']) and calling OodAppkit.clusters[ENV['OOD_CLUSTER'].to_sym] to retrieve the appropriate cluster config. But this requires coordination from the sysadmin side to ensure that variable is always correctly set, which may not be simpler than just specifying the cluster statically in the form.

In short, there’s no built-in API in OOD to automatically detect or dynamically select the current cluster within the form that I know of. Any dynamic behavior would need to be implemented manually, likely scripting and environment variables, and even then it’s unclear how reliable or maintainable that approach would be.

As always, it could be there’s a way here that is just not documented or known, but I am unsure myself.

3

Thanks Travis for your answer. I’m trying to isolate the application form from the cluster definition and want to inject enhanced attribute to the default partition names.
The fact is that when there are multiple clusters, a dropdown is automatically added by OOD, so maybe the way I’m doing it is not the right one. At the GOOD conference there were some examples presented with initializers and plugins, I may investigate that path too.

If someone else has an example to share on how to dynamically query partitions other than autoqueues, I will be pleased to try.

Thanks,
Xavier

4

That reminds me to update that portion of the tutorial to include the ondemand.d configuration for global_bc_form_items.

I think you could use either, but ondemand.d configuration may be cleaner.

In any case, I think the resolution is simple - you create a list of all the queues on all clusters, then attach dynamic data- directives to it so they’ll be able to show and hide themselves based on the current choice of cluster.

Technically they’ll be there in the HTML, but the user won’t see them in the dropdown given the rules you apply to them.

data-option-for-cluster-

and new in 4.0 we have data-exclusive-option-for-

5

Thank you Jeff.
I was finally able to make it works by doing this :

  • define the cluster list and names in global_bc_form_items as a hidden text field in case of a simple cluster or a select if multiple
  • define a global partition list with all partitions for all clusters which can be filtered using the data-exclusives attributes

By doing this way I can isolate my application form from the cluster and partition definitions and build a dynamic cluster registration mechanism.

Xavier