JobComposer: Support admins adding custom fields to job options

[ericfranz]

See https://discourse.osc.edu/t/job-composer-additional-fields/50 and OSC/ood-myjobs#265

While we are looking at a better way to support customizing the job options, we are providing this information to admins to modify existing apps right now. It would seem that at least supporting this approach by adding code or files under /etc/ood/apps/myjobs/ should be doable without too much work.

In the short term we could adopt the same submit.yml and form.yml that we do with the interactive apps, even though in the long term we would like to simplify our approach to things.

One problem with the described approach is that it does not address cluster specific attributes.

[ericfranz]

From OSC/ood-myjobs#242:

The problem observed by University of Arizona:

• this is in regards to PBS Pro
• our library includes a resource-manager agnostic attribute for "account" (for PBS Pro it is added as the command line argument "-A <account_string>")

The issue is that University of Arizona doesn't use this field for accounting purposes. Instead they use the "--group_list <g_list>" for accounting purposes.

We either allow customization at the app level, library level, or make input fields toggle-able. Other suggestions are appreciated.

[ericfranz]

One approach would be to piggy back off of the batch connect plugin format, except you would have a separate form per cluster.

You implement the "glue" code in one commit (the OSC/ood-myjobs#265 PR with the changes to app/models/job.rb and app/models/resource_mgr_adapter.rb for passing workflow:

• https://github.com/OSC/ood-myjobs/blob/e3a0b67f01f87dd7ba505a17aecc64645a69032c/app/models/resource_mgr_adapter.rb#L7-L11
• https://github.com/OSC/ood-myjobs/blob/e3a0b67f01f87dd7ba505a17aecc64645a69032c/app/models/job.rb#L18
• https://github.com/OSC/ood-myjobs/blob/e3a0b67f01f87dd7ba505a17aecc64645a69032c/app/models/workflow.rb#L161

Now you would be left with taking the form.yml and submit.yml for Job Compser and resulting in:

1. rendering the form in the job options https://github.com/OSC/ood-myjobs/blob/e3a0b67f01f87dd7ba505a17aecc64645a69032c/app/views/workflows/_edit_form_job_attrs.html.erb#L9-L11
2. appending to :job_attrs array the name of the key's for the form elements https://github.com/OSC/ood-myjobs/blob/e3a0b67f01f87dd7ba505a17aecc64645a69032c/app/models/workflow.rb#L11
3. rendering the OodCore::Job::Script object https://github.com/OSC/ood-myjobs/blob/e3a0b67f01f87dd7ba505a17aecc64645a69032c/app/models/resource_mgr_adapter.rb#L31-L37

form.yml

owens: !!omap # key is cluster, not "attributes:" and we use omap
  - account: {}
  - nodes: {}
default: !!omap # default array of attributes
  - account: {}

• would have to be an array of hashes instead of a hash because YAML hashes aren't guarenteed to retain order; well there is https://yaml.org/type/omap.html for an ordered map, which is supported by Ruby's Hash though I haven't tested how Ruby 2.4 handles loading omap
• could avoid "merging" anything: you see what you get

submit.yml only defines the script this time.

[johrstrom]

This is being taken up in #859