diff --git a/.gitignore b/.gitignore
index cc53b3f6..55a81587 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,12 +2,18 @@
.DS_Store
# bundle
-Gemfile
-Gemfile.lock
+# Anchored to the repo root so the misc/Gemfile template stays tracked — the
+# install docs tell administrators to copy it here.
+/Gemfile
+/Gemfile.lock
vendor/
.bundle
-TODO_ja.md
+
+# Local site configuration, copied from conf.yml.erb.sample
conf.yml.erb
+# Passenger restart trigger
+tmp/
+
# Regenerated from docs by misc/tests/run_tests.rb
misc/tests/samples/
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 94c0e197..2f6af533 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,43 @@
# Changelog
+## [Unreleased]
+### Add
+- Add an OOD-integrated (embedded) mode that renders Open Composer inside Open OnDemand's own navbar and footer, via a reverse-proxy dashboard initializer under `ood_integration/` and without an iframe.
+- Add an All Templates page (`/all_templates`) listing every template as one flat list, including applications hidden from the index page.
+- Add custom templates: save the current form values as a reusable template, then rename, re-describe, delete or reorder them from the index page.
+- Add a "Load or Create a Script from Disk" file browser that opens an existing batch script in the generic scheduler form with its location and name pre-filled.
+- Add New Script and New Custom Template pickers for choosing which application to start from.
+- Add a Nodes page listing the cluster's compute nodes with their state, CPU, memory and generic resources, with one dynamically discovered column per GRES type.
+- Add a `module_load` widget: a dropdown of every available version of an environment module, which rewrites the existing `module load` line in place so surrounding script lines are preserved.
+- Add a `dependent_module_select` widget whose module list follows the value of another widget.
+- Add `remember_last` to `select` widgets, restoring the user's previous choice from browser storage.
+- Add script-to-form parsing, so editing the script pane, or opening a job from the history page, reconstructs the form from the script's scheduler directives.
+- Add an empty-script submission warning (`empty_script_warning`).
+- Add a Job Efficiency panel to the history page (`history_efficiency`), reporting wall time, CPU, memory and, for GPU jobs, GPU utilization and GPU memory.
+- Add output and error columns to the history page, with an in-page file viewer.
+- Add "Cancel All Jobs", "Delete All History" and "Refresh" actions to the history page, plus per-job cancellation with progress reporting.
+- Add optional SSH key provisioning on submit (`ensure_ssh_key`), disabled by default.
+- Add a `modules_list_url` setting for the module catalog behind the module widgets.
+- Add `home_format`, `category_badge_colors`, `accent_color`, `body_text_color`, `gpu_memory` and `favicon` settings.
+- Add `hidden`, `documentation` and `tags` manifest keys, and allow `category` to be given as a list.
+
+### Changed
+- Use `sacct` as the source of truth on the history page, so jobs submitted outside Open Composer also appear, with their script fetched live.
+- Move the generic per-scheduler script templates to `generic_apps_dir`, reachable at `/_generic/
name: Gaussian
-category: Quantum Chemistry
+category: Chemistry
+tags:
+ - gpu
icon: icon.png
-description: |
- [Gaussian](https://gaussian.com) is a general purpose computational chemistry software package.
+description: Gaussian is a general purpose computational chemistry software package.
+hidden: true
+homepage: https://gaussian.com/
+documentation: https://docs.example.org/applications/gaussian/
related_apps:
OVITO:
icon: ovito.png
@@ -71,16 +82,24 @@ 1.1. manifest.yml
ImageJ:
icon: bi-airplane-fill. For Font Awesome icons, write icon: fa-solid fa-gear.Application, and a category of Others is sorted after all the others.
+ A list of categories is also accepted, but it only has an effect on the listings that treat the entries individually: the All Templates and New Script lists draw one badge per entry (colored from category_badge_colors in conf.yml.erb, gray when the category is not listed there), the navbar search box matches and badges each entry, and the application counts as featured if any entry matches new_script_featured_category. Sorting uses the first entry as the primary category.
+ A list places the application under each of its categories on the home page and on the New Custom Template page, so it appears once per category. Category headings follow the same order as for single-valued categories.gpu (matched case-insensitively): it adds a black GPU badge to the application's row in the All Templates and New Script lists and in the navbar search results. Other tags are read but have no effect. Applications whose name matches a GPU-domain module in the site module list are badged automatically and need no tag.http:// or https:// URL is used as it is; otherwise the value is treated as a path relative to the application's own directory and used if that file exists; otherwise, if it begins with bi- or fa-, it is rendered as an icon font class — the whole value becomes the class attribute, so icon: bi-airplane-fill (Bootstrap icon) and icon: fa-solid fa-gear (Font Awesome icon) both work; otherwise the built-in app_default.svg placeholder is used silently, with no error message. bi- and fa- are the only prefixes recognized, so the fas fa-gear and fas://name spellings used in Open OnDemand's own manifests fall through to the placeholder here. Keep the file in the application directory itself rather than a sub-directory, and remember that a placeholder tile usually means a mistyped file name. If icon is omitted, app_default.svg is used.true, the application is left out of the home page listing and out of the categorized list on the New Custom Template page. It is still listed on the All Templates and New Script pages, still appears in the New Custom Template page's search results, is still offered by the navbar search box, and is still reachable by a direct link or by inheritance. Use it to keep the home page focused while a large catalog stays searchable — not to restrict access. The default is false.icon:, you can specify icon images, etc. If no image is specified, the image registered in Open OnDemand is used.
The form.yml is composed of five main sections: form, script, header, check and submit.
- The form and script sections are required fields, but header, check and submit sections can be omitted.
+ Only form is required: if the parsed document has no top-level form: key, the page fails with In ./<file>, "form:" must be defined.
+ The body of form may be empty, however — a bare form: with no widgets below it is legal, and renders just the header fields and the script area (the generic applications under generic_apps_dir are written exactly this way).
+ The script, header, check and submit sections can all be omitted. With no script section nothing is generated for the script area, which simply starts empty for the user to type into or for a loaded script to fill.
The following figure shows the scope of form, script, and header sections.
@@ -106,6 +125,8 @@
label is the displayed name,
value is the default value,
min and max set the range, and step determines the increment.
- The required key specifies whether the input is mandatory, and help provides a tooltip below the input field.
+ The required key specifies whether the input is mandatory, and help is static help text rendered in small print underneath the input field. It is always visible; it is not a tooltip.
The script section specifies how the input value will appear in the job script.
The #{nodes} in the script section will be replaced with the input value.
@@ -263,6 +284,28 @@
+
+ Setting remember_last: true on a select widget causes the browser to remember the last value the user selected and restore it automatically the next time they visit the form.
+ This is useful for fields like a project or partition selector that users rarely change between job submissions.
+
form:
+ partition:
+ widget: select
+ label: Partition
+ remember_last: true
+ options:
+ - [ Small Queue, small ]
+ - [ Large Queue, large ]
+
+script: |
+ #SBATCH --partition=#{partition}
+
+ The remembered value is kept in the browser's local storage under a key made from the widget's name, and the string stored is the option's displayed text (the first element of the option array).
+ Because the key is the widget name alone, two applications that use the same widget name share a single remembered value — which is what lets a common account or partition selector follow the user across applications, but is surprising if it was not intended.
+ If an option's displayed text is later changed, the stored string no longer matches any option and nothing is restored.
+ Restoring is skipped entirely when a form is opened from a saved template or from the History page, so the values those pages pre-fill always win.
+ Only plain select widgets honor remember_last.
+
@@ -427,7 +470,123 @@
-
+ Displays a dropdown listing the installed versions of one named environment module.
+ The entries are not written in form.yml: the widget renders a single dropdown showing Loading…, and the browser fills it in after the page has loaded by asking the application's /_module_avail route for the versions of the module.
+
+ The module key is required and holds the module name to look up.
+ The name is matched case-insensitively against the module list, and the entries offered are the full Name/version strings built from the spelling used in that list.
+ The entries are sorted in descending string order — a plain text comparison, not a version-aware one, so Python/3.9.5 is listed above Python/3.11.6 — and the module's default version, if the list gives one and that version appears among the module's own versions, is then moved to the top.
+
+ Besides module, the keys honored are label, value, help and indent.
+ value pre-selects the entry that matches it exactly, written in full Name/version form; if it matches nothing, the first entry is selected.
+ An options key is ignored — the entries always come from the module list.
+ required is accepted, but its only effect is to append an asterisk to the label; it is not enforced when the form is submitted.
+
form:
+ gromacs_module:
+ widget: module_load
+ label: GROMACS module
+ module: GROMACS
+ help: Only versions installed on the cluster are listed.
+
+script: |
+ module load #{gromacs_module}
+ gmx mdrun -s topol.tpr
+
+ If the module name is not in the list — or if the module key is missing — the dropdown holds a single empty entry labeled No modules found; if the request itself fails, it shows Error loading modules.
+ In both cases the widget's value is empty, so a script line that refers to it is left out of the job script, unless the reference is written #{:gromacs_module} (see section 10).
+
+ When the widget is referenced in the script and/or submit section, changing the selection rewrites the existing module load line in place instead of regenerating the script.
+ Every line that consists of module load on its own, or of module load followed by this widget's own module name with or without a version, is replaced by module load plus the new selection, keeping the line's original indentation; nothing else in the text area is touched, including lines the user has typed.
+ If no such line is present yet, the widget falls back to the normal script update, which inserts the line from the template.
+
+ The module list itself is a JSON file cached under data_dir as .module-list-cache.json and refreshed at most once every 24 hours; the same list is used for every cluster. See Network and external dependencies in the installation document for where it is downloaded from.
+ Because the widget has no options of its own it cannot drive the actions described in section 3, but it can be their target (for example hide-gromacs_module or disable-gromacs_module).
+
+ Displays a dropdown whose options are loaded dynamically according to the currently-selected value of a driver widget.
+ Use it when one select widget (e.g. an application version) determines which set of modules should be offered in a second select.
+ As with the module_load widget (section 2.9), the entries come from /_module_avail after the page has loaded, and the dropdown shows Loading… until they arrive.
+
+ The driver key names the field whose value is watched. It must name a widget that is rendered on the same page; if it does not, the dropdown stays on Loading….
+ The string tested is the driver option's value — the second element of its options array — not the text displayed in the dropdown. (As elsewhere, an option with no second element falls back to its first element.)
+
+ The options key is a list of matcher entries. Each entry names a module and, optionally, one of two matchers:
+
prefix: matches when the driver's value starts with the given string.contains: matches when the driver's value contains the given string anywhere.
+ The entries are tried in the order they are written and the first match wins, so list more specific matchers before more general ones. Within a single entry, prefix: is tested before contains:.
+ If no entry matches, the module of the last entry in the list is used as a fallback, which makes it natural to put the general case last (an entry with a module and no matcher can never match on its own, so as the last entry it acts purely as a default).
+ Whenever the resolved module name changes the version list is re-fetched and the first entry of the new list is selected; if the resolved name does not change, the dropdown is left as it is.
+
form:
+ alphafold_module:
+ widget: select
+ label: AlphaFold Module
+ options:
+ - [AlphaFold 2.3.2, AlphaFold/2.3.2]
+ - [AlphaFold 3.0.0, AlphaFold/3.0.0]
+ - [AlphaFold 3.0.1, AlphaFold/3.0.1]
+ - [AlphaFold 3.0.2, AlphaFold/3.0.2]
+
+ alphafold_db_module:
+ widget: dependent_module_select
+ label: AlphaFold Database Module
+ driver: alphafold_module
+ options:
+ - prefix: AlphaFold/2.
+ module: AlphaFold2DB
+ - prefix: AlphaFold/3.
+ module: AlphaFold3DB
+
+script: |
+ module load #{alphafold_module}
+ module load #{alphafold_db_module}
+
+ In this example, selecting AlphaFold/2.3.2 in the driver loads the available versions of AlphaFold2DB, while selecting AlphaFold/3.0.0, AlphaFold/3.0.1, or AlphaFold/3.0.2 loads the versions of AlphaFold3DB.
+ Note that the prefixes are tested against the option values (AlphaFold/2.3.2 and so on), not against the labels shown in the dropdown.
+
+
+ The example below uses contains: instead, because the distinguishing part of the driver's value is not at the start of the string.
+ Any CUDA version whose value contains -gpu selects cuDNN-GPU; anything else falls through to the last entry, which has no matcher and therefore acts as the default.
+
form:
+ cuda_module:
+ widget: select
+ label: CUDA Module
+ options:
+ - [CUDA 11.8, CUDA/11.8.0 ]
+ - [CUDA 12.0 (GPU), CUDA/12.0.0-gpu ]
+ - [CUDA 12.3 (GPU), CUDA/12.3.0-gpu ]
+
+ cudnn_module:
+ widget: dependent_module_select
+ label: cuDNN Module
+ driver: cuda_module
+ options:
+ - contains: -gpu
+ module: cuDNN-GPU
+ - module: cuDNN
+
+script: |
+ module load #{cuda_module}
+ module load #{cudnn_module}
+
+
The zeropadding(key, digit) function pads a number with leading zeros.
If the number of digits is less than the value specified in the second argument, digit, the missing digits are filled with '0'.
@@ -489,8 +648,16 @@
- Sets the min, max, step, label, value, required, and help.
- Specifies set-(min|max|step|label|value|required|help)-(KEY)[_(num|1st element in options)]:(VALUE) from the third element and onward of each options array.
+ Sets the min, max, step, label, value, required, or help of another widget.
+ Each action is written as a YAML mapping entry from the third element onward of an options array, in one of the following shapes:
+
set-(min|max|step|label|value|required|help)-(KEY): (VALUE) — targets the whole widget KEY.set-(min|max|step|label|value|required|help)-(KEY)_(num): (VALUE) — an underscore followed by a 1-based field number targets one input field of a multi-field widget, e.g. set-max-time_1: 24. This shape is recognized only for number, text and email widgets.set-required-(KEY)-(1st element in options): (true|false) — a hyphen followed by an option's first element targets one option of a checkbox widget. This shape is recognized only for set-required- on checkbox widgets; no other set- attribute accepts an option name.
+ The value is type-checked: min, max and step must be numbers, and required must be true or false.
In the following example, if you select Medium for node_type, the label and maximum value for cores will be Number of Cores (1-8) and 8.
@@ -546,8 +713,9 @@
- For select, radio, and checkbox widgets,
- use 1st element in options to specify the target option.
+ For select, radio, and checkbox widgets the option is not named in the action itself:
+ use set-value-(KEY) and give the option's first element as the value.
+ The option whose displayed text is exactly equal to that value is then selected or ticked; if no option matches, the widget is left unchanged.
In the following example, when you select GPU for node_type, Enable GPU for enable_gpu is checked.
form: @@ -566,16 +734,32 @@3.1. Widget setting
script: | #SBATCH --partition=#{node_type}
+
+ set-min-, set-max-, set-step-, set-label-, set-help- and set-required- are re-evaluated whenever any driving widget changes, so when the option that set them is no longer selected the target returns to the value declared in its own form entry.
+ set-value- behaves differently: it is applied when its option is selected and is never undone, so the target keeps the last value written to it.
+ In the first example above, choosing Medium and then Small again restores max to 4, but a value written by set-value- would stay.
+ Give every option its own set-value- action when you need the value to change back.
+ On a checkbox or radio target, set-value- can only tick the option whose text matches; it never unticks one.
+
Disables or enables the widget.
- Specifies [disable|enable]-(KEY)[-(1st element in options)][_num] for the third element and onward of each options array.
+ Each action is written as a plain string (not a mapping entry) from the third element onward of an options array, in one of the following shapes:
+
[disable|enable]-(KEY) — the whole widget KEY, whatever its widget type.[disable|enable]-(KEY)-(num) — a hyphen followed by a 1-based field number targets one input field of a multi-field number, text or email widget. Note that the separator here is a hyphen, unlike the underscore used by the set- actions in section 3.1.[disable|enable]-(KEY)-(1st element in options) — a hyphen followed by an option's first element targets one option of a select, multi_select, radio or checkbox widget.
+ Unrecognized action names are ignored silently, with no warning.
+ The widget name and the option text are placed directly into a regular expression when the action is matched, so avoid regular-expression metacharacters (for example ., *, +, ?, |, (, ), [) in the first element of any option you intend to target this way.
In the following example, when Fugaku is selected for cluster,
the GPU option for node_type and the cuda_ver widget will be disabled.
- If a key is disabled, its line in the script section will also be deleted.
+ If a key is disabled, its line in the script section will also be deleted, unless the reference is written with a leading colon (for example #{:cuda_ver}), in which case the line is still output with the value replaced by an empty string (see section 10).
form: cluster: @@ -665,34 +849,45 @@4. Available combinations
Widget label, value, help,
required, indentoptions size separator direction min, max, -
stepshow_files, +
favoritesshow_files,
favoritesremember_last - number OK OK OK + number OK OK OK - text, email OK OK + text, email OK OK - select OK OK + select OK OK OK - multi_select OK OK OK + multi_select OK OK OK + radio OK OK - OK + OK + + checkbox OK OK OK OK - checkbox OK OK OK OK + path OK OK - +path OK OK +module_load label, value, help, indent module
(see 2.9)+ + +dependent_module_select label, help, indent driver, prefix/contains/module
(see 2.10)+ The
headersection renders fewer widget types than theformsection: onlynumber,text,select,multi_select,radio,checkboxandpathare drawn there. + Amodule_loadordependent_module_selectwidget placed in theheadersection is silently skipped — no dropdown is drawn and no module list is fetched. + Define those two widgets in theformsection only. +5. Script section
5.1. Change label
@@ -771,28 +966,49 @@5.4. Special variables
name of manifest.ymlmanifest.yml and related files are stored (the last path element of each application’s URL).Script Location defined in the header sectionCluster name defined in the header section (This is only available when cluster is defined in ./conf.yml.erb)Cluster name defined in the header section (This is only available when more than one cluster is defined under clusters: in ./conf.yml.erb, because lib/header.yml.erb only draws the _cluster_name widget in that case)Script Name defined in the header sectionJob Name defined in the header section
- If you try to modify a widget that affects the script or submit section after manually editing those sections, a warning like the one below will appear.
- If you click "Discard and continue", the changes you made to the section will be discarded and a new script will be generated.
+ The script area works in both directions. As well as the widgets writing the script, Open Composer reads the script back and updates the widgets from it: when a saved script is loaded (from the History page, or from disk through the file browser) the form is reconstructed from the script's contents, and while the user edits the script by hand the widgets follow along, about half a second after the last keystroke.
+ This is done by matching each line of the script against a pattern derived from the corresponding line of the script template, so whether a field can be recovered from a script depends on how its template line is written.
- To disable this warning, set overwrite_warning: false in the configuration of the section where you want to disable the warning.
+ The rules to follow when writing template lines are:
+
#{...} is not empty, so a line that begins with an interpolation (e.g. #{command} -n 4) is never matched back to its widget.#SBATCH --ntasks=) both fields will read the same script line.calc(), zeropadding(), dirname() or basename() cannot be reversed: its pattern is registered for placement purposes only, with no fields attached to it. Plain #{key} interpolations are reversed, and a line may contain any number of them — each becomes a capture group whose text is written back to that widget.#SBATCH --time= and does use those functions is handled by a dedicated Slurm-time parser. It accepts every Slurm --time format (D-HH:MM:SS, D-HH:MM, D-HH, HH:MM:SS, MM:SS and MM) and fills the line's fields, in the order they appear in the template, with days, hours, minutes and seconds. Any field beyond the fourth is set to 0, so the time fields must be written in exactly that order.+ The captured text is applied according to the target widget: +
+number, text, email: written straight into the input field.select, module_load, dependent_module_select: the option whose value (the second element of its options array) equals the captured text is selected. Nothing happens if no option matches, or while the widget is disabled.radio: the button whose value equals the captured text is selected.checkbox: the captured text is split on the widget's separator (a comma if none is set), and every option whose value appears in the result is ticked.multi_select and path: not applied. The reverse parser has no case for these two widget types, so text captured for them is discarded and the field keeps whatever it already held — the cd #{working_dir} line of section 2.8, for instance, is not read back. A path field is still pre-filled on the server in the History case described below, when its template line starts with #SBATCH.
+ When a script is loaded, a matched line may also open a hidden section: if the field it belongs to is disabled, the enable- actions that control that field are triggered so the section appears with the loaded value already in it.
+ For the number, text, email and Slurm-time cases this happens only when the line is unique to that field — if the same line also matches a pattern belonging to another widget, the value is still applied but no section is opened.
+ For example, if two fields both emit #SBATCH --ntasks=, an advanced section is opened only by a line that belongs to it alone, such as its own #SBATCH --cpus-per-task= line.
+ While the user is typing in the script area, no section is ever opened and disabled fields are left untouched.
+
+ When a job's script is not held in the history database — because history_store_script is false, or because Open Composer did not submit the job — the script is fetched from the scheduler with sacct -B and the widgets' value keys are additionally pre-filled on the server, before the page is rendered. That path is narrower than the one described above: a template line is considered only if it starts with #SBATCH, and it is matched only against script lines that start with #SBATCH. On an ordinary History load the stored script is used as it is and all widget reconstruction happens in the browser.
+ Every other line of the script is ignored, which means that on a non-Slurm scheduler this server-side step does nothing.
+ zeropadding(field, N) is understood there; the other functions are not, and their captures are discarded.
+ The script template is also read as plain text, so an application that writes its script with label: and content: keys (see section 5.1) gets no server-side pre-fill.
+ In all of these cases the parsing done in the browser still runs, so the form still ends up matching the loaded script.
script: - overwrite_warning: false - content: |- -
submit: - overwrite_warning: false - content: |
Variables defined in the form section can be validated in the check section using the Ruby language and the function oc_assert(condition, message).
@@ -825,7 +1041,7 @@
name of manifest.ymlmanifest.yml and related files are stored (the last path element of each application’s URL).Script Location defined in the header sectionCluster name defined in the header section (This is only available when cluster is defined in ./conf.yml.erb)Cluster name defined in the header section (This is only available when more than one cluster is defined under clusters: in ./conf.yml.erb)Script Name defined in the header sectionJob Name defined in the header section
- If you also set action: save in the script section, its contents will be saved before executing the commands in the submit section.
+ The job script is always written to Script Location/Script Name before the commands in the submit section run — this is what makes the mv #{OC_SCRIPT_NAME} … in the example above work. Setting action: save in the script section only suppresses the job submission that would otherwise follow the submit section.
The button at the bottom of the "Confirm" screen will change from "Submit" to "Save," as shown below.
+
+ When the user submits the form — with the Submit button, or with the Submit button inside the confirmation dialog of an action: confirm application, since clicking Confirm itself only opens that dialog — Open Composer automatically checks whether the batch script contains any real commands.
+ A line is considered boilerplate and ignored if it is blank, starts with # (comments, #SBATCH directives, or the shebang line), or starts with module.
+ If no real commands are found, a browser confirmation dialog is shown before the job is submitted:
+
No commands have been added to the batch script. + +Are you sure you want to submit?+
+ Clicking Cancel returns the user to the form without submitting.
+ Clicking OK proceeds with submission as normal.
+ This check is automatic and enabled by default. It does not apply to an application whose script section sets action: save, because that writes a file instead of submitting a job.
+
+ To disable the warning, set empty_script_warning: false in conf.yml.erb:
+
empty_script_warning: false+
+
You can define the header section.
@@ -891,7 +1127,7 @@
The example below defines a new widget, script_content, that hides the job script.
- The _script_location and _script are widgets defined in lib/header.yml.erb (if a cluster is defined in ./conf.yml.erb, you must also define _cluster_name).
+ The _script_location and _script are widgets defined in lib/header.yml.erb (if more than one cluster is defined under clusters: in ./conf.yml.erb, you must also define _cluster_name).
header: @@ -936,15 +1172,124 @@-8. Header section
- [large] <% end %>
+ When a form file is named form.yml.erb, Open Composer processes it as Embedded Ruby (ERB) before parsing the YAML.
+ This lets you generate form content dynamically at page load time — for example, running a shell command to build the list of options for a dropdown, or reading values from the OpenComposer configuration.
+
+ The variable @conf is available inside form.yml.erb and contains the full OpenComposer configuration hash loaded from conf.yml.erb.
+ It is set only while a page is being rendered. The same form.yml.erb is re-evaluated when the form is submitted, and on that request @conf is nil — so always use safe navigation (@conf&.fetch('login_node', nil)) or wrap the lookup in begin/rescue, otherwise submitting the form fails with a NoMethodError page instead of submitting the job.
+ Use it to read site-specific settings such as the login node hostname.
+
<%
+ login_node = @conf&.fetch('login_node', nil)
+%>
+---
+form:
+ my_field:
+ widget: text
+ label: Login node is <%= login_node %>
+
+
+ You can run a shell command inside ERB to populate a select widget's options list at page load time.
+ If the OOD web server does not have direct access to the job scheduler daemon, prefix the command with
+ ssh to the login node. Use @login_node, which Open Composer has already resolved for the cluster the user selected (@cluster_name is available too); @conf['login_node'] is the raw setting and is a Hash keyed by cluster name on a multi-cluster site.
+
+ The example below populates a "Project" dropdown from the user's Slurm associations by running sacctmgr via SSH.
+ It always renders a select widget — if no accounts are found the options list is empty rather than crashing.
+
<%
+ begin
+ _login_node = (@conf&.fetch('login_node', nil) rescue nil)
+ _login_node = _login_node.is_a?(Hash) ? _login_node.values.compact.first : _login_node
+ _ssh_prefix = _login_node ? "ssh -o BatchMode=yes -o ConnectTimeout=10 #{_login_node}" : ""
+ _accounts = `#{_ssh_prefix} sacctmgr -n -P show user #{ENV['USER']} withassoc format=Account 2>/dev/null`
+ .split("\n").map(&:strip).reject(&:empty?).uniq.sort
+ rescue
+ _accounts = []
+ end
+%>
+---
+form:
+ account:
+ widget: select
+ label: Project
+<% if _accounts.empty? %>
+ options: []
+<% else %>
+ options:
+<% _accounts.each do |a| %>
+ - ["<%= a %>", "<%= a %>"]
+<% end %>
+<% end %>
+
+script: |
+ #SBATCH --account=#{account}
+ + Key points: +
+begin/rescue block so a failed command produces an empty list rather than a form error.options: [] (not omitting the key) when the list is empty — a missing options key parses as nil in YAML and causes a runtime error.BatchMode=yes prevents SSH from hanging waiting for a password; ConnectTimeout=10 prevents the page from stalling if the login node is unreachable.
+ Use the read_yaml(path) helper to load another form file (including .erb files) and then modify its content before emitting YAML.
+ This is how the applications in the apps/ directory inherit their common Slurm fields from one of two base forms: SlurmBasic for CPU jobs, or SlurmGPU — which adds the partition-aware GPU type and GPU-count selectors and the corresponding --gpus-per-node script lines — for GPU jobs. Point base_path at whichever one matches your application.
+
+ Inside a form.yml.erb, the local variable yml_path holds the path of the form file being processed, always written without the .erb suffix (for example ./apps/MyApp/form.yml), so File.dirname(yml_path) is the application's own directory.
+
<%
+base_path = File.join(File.dirname(yml_path), '../SlurmBasic/form.yml')
+base = read_yaml(base_path)
+
+# Insert an application-specific field before the time widget
+new_form = {}
+base['form'].each do |k, v|
+ if k == 'time_days_hours_minutes'
+ new_form['myapp_module'] = {
+ 'widget' => 'module_load',
+ 'module' => 'myapp',
+ 'label' => 'MyApp Module'
+ }
+ end
+ new_form[k] = v
+end
+
+base['form'] = new_form
+base['script'] = base['script'].rstrip + "\n\n" + <<~'APP_SCRIPT'
+ module load #{myapp_module}
+APP_SCRIPT
+%>
+<%= base.to_yaml -%>
+
+ Note the single-quoted heredoc (<<~'APP_SCRIPT'). Any script text containing #{...} must be written in a single-quoted heredoc or a single-quoted Ruby string: #{...} is Open Composer's form interpolation syntax, but inside a <% %> block a double-quoted string would make Ruby try to interpolate the widget name first, and the page would fail with NameError: undefined local variable or method 'myapp_module'.
+
+ read_yaml automatically finds and processes the .erb version of the file if it exists, so SlurmBasic's ERB header (which populates the Project dropdown) is executed correctly when inherited.
+
submit section can only be written in the Bash language.nodes_1). The same rule applies to the directory name in which the application is saved. However, when defining the header section in form.yml, the widget names beginning with underscores (e.g. _script_location) used in lib/header.yml.erb can be used.options, the first element is used instead.label and help texts are inserted into the page as HTML rather than as plain text, so simple markup such as <br>, <b>, <code> or an <a href="…" target="_blank"> link can be used in them. The same applies to text supplied by a set-label- or set-help- action. Because of this, a literal < must be written as < and a literal & as &; a double quote in a label also breaks the attribute the label is copied into, so write it as ". Note that markup in a label is flattened to plain text if a set-required- action later rewrites that label. The first and second elements of an options array are escaped and always appear literally.module_load and dependent_module_select values reach the check section as the selected Name/version string, so @my_module can be validated like any text field.script section, if a variable used in a line does not have a value, the line is not displayed. However, if you add a colon to the beginning of the variable (e.g. #{:nodes} or #{basename(:input_file)}), the line will be output even if the variable does not have a value.empty_script_warning is enabled, check whether the batch script contains any real commands and show a confirmation dialog if not (see section 7.1)check section in form.yml (if the check section exists)submit section in form.yml (if the submit section exists)
-
+ 指定した1つの環境モジュールについて、インストールされているバージョンを一覧するドロップダウンを表示します。
+ 項目はform.ymlには記述しません。ウィジットはLoading…と表示された1つのドロップダウンを描画し、ページの読み込み後にブラウザがアプリケーションの/_module_availにそのモジュールのバージョンを問い合わせて項目を埋めます。
+
+ moduleキーは必須であり、検索するモジュール名を指定します。
+ モジュール名は大文字と小文字を区別せずにモジュールの一覧と照合され、提示される項目は、その一覧で用いられている表記から組み立てられた完全なName/versionの文字列です。
+ 項目は文字列の降順に並びます。バージョンを考慮した比較ではなく単純な文字列の比較であるため、Python/3.9.5がPython/3.11.6より上に並びます。その後、一覧がデフォルトのバージョンを示しており、かつそのバージョンがそのモジュール自身のバージョンに含まれている場合に限り、それが先頭に移動されます。
+
+ moduleのほかに有効なキーはlabel、value、help、indentです。
+ valueは、完全なName/versionの形式で記述し、それと完全に一致する項目を既定で選択します。一致するものがない場合は先頭の項目が選択されます。
+ optionsキーは無視されます。項目は常にモジュールの一覧から取得されます。
+ requiredは受け付けられますが、その効果はラベルにアスタリスクを付加することのみであり、フォームの投入時に強制されることはありません。
+
form:
+ gromacs_module:
+ widget: module_load
+ label: GROMACS module
+ module: GROMACS
+ help: Only versions installed on the cluster are listed.
+
+script: |
+ module load #{gromacs_module}
+ gmx mdrun -s topol.tpr
+
+ モジュール名が一覧に無い場合、またはmoduleキーが無い場合、ドロップダウンはNo modules foundというラベルの空の項目1つだけになります。問い合わせ自体が失敗した場合はError loading modulesと表示されます。
+ いずれの場合もウィジットの値は空になるため、それを参照するスクリプトの行はジョブスクリプトから除かれます。ただし、参照を#{:gromacs_module}と記述した場合は除かれません(10. 補足を参照)。
+
+ このウィジットがscriptセクションやsubmitセクションで参照されている場合、選択を変更すると、スクリプトを再生成するのではなく、既存のmodule loadの行がその場で書き換えられます。
+ module loadのみからなる行、およびmodule loadに続いてこのウィジット自身のモジュール名(バージョンの有無は問いません)が記述されている行はすべて、module loadと新しい選択に置き換えられ、その行の元のインデントは維持されます。テキストエリア内のそれ以外の部分は、ユーザが入力した行を含めて一切変更されません。
+ 該当する行がまだ存在しない場合は、通常のスクリプトの更新に戻り、テンプレートから行が挿入されます。
+
+ モジュールの一覧そのものは、data_dir以下に.module-list-cache.jsonとしてキャッシュされるJSONファイルであり、更新は最大でも24時間に1回です。同じ一覧がすべてのクラスタで使用されます。取得元については、インストールマニュアルのネットワークと外部への依存を参照してください。
+ このウィジットは自身のoptionsを持たないため、3. Dynamic Form Widgetで説明する動作の起点にはなれませんが、その対象にはなれます(例えばhide-gromacs_moduleやdisable-gromacs_module)。
+
+ driverとなるウィジットの現在の選択値に応じて、選択肢が動的に読み込まれるドロップダウンを表示します。
+ あるselectウィジット(例えばアプリケーションのバージョン)が、2つ目のselectで提示すべきモジュールの集合を決定する場合に使用します。
+ module_loadウィジット(2.9. module_loadウィジット)と同様に、項目はページの読み込み後に/_module_availから取得され、それが届くまでドロップダウンはLoading…と表示します。
+
+ driverキーは、値を監視する対象の項目名を指定します。同じページに描画されるウィジットを指定しなければなりません。そうでない場合、ドロップダウンはLoading…のままになります。
+ 判定に用いられる文字列は、driverの選択肢の値、すなわちoptions配列の2つ目の要素であり、ドロップダウンに表示される文字列ではありません(他の箇所と同様に、2つ目の要素が無い選択肢は1つ目の要素が代わりに用いられます)。
+
+ optionsキーは、照合条件の一覧です。各項目はmoduleを指定し、任意で次の2つの照合方法のいずれかを指定します。
+
prefix: driverの値が指定した文字列で始まる場合に一致します。contains: driverの値が指定した文字列をどこかに含む場合に一致します。
+ 項目は記述された順に試され、最初に一致したものが採用されるため、より限定的な条件をより一般的な条件より前に記述してください。1つの項目の中では、prefix:がcontains:より先に判定されます。
+ どの項目も一致しない場合は、一覧の最後の項目のmoduleがフォールバックとして使用されます。そのため、一般的な場合を最後に置くのが自然です(moduleのみで照合方法を持たない項目は、それ自体では決して一致しないため、最後の項目として置くと純粋に既定値として機能します)。
+ 解決されたモジュール名が変化するたびにバージョンの一覧が再取得され、新しい一覧の先頭の項目が選択されます。解決された名前が変化しない場合、ドロップダウンはそのままになります。
+
form:
+ alphafold_module:
+ widget: select
+ label: AlphaFold Module
+ options:
+ - [AlphaFold 2.3.2, AlphaFold/2.3.2]
+ - [AlphaFold 3.0.0, AlphaFold/3.0.0]
+ - [AlphaFold 3.0.1, AlphaFold/3.0.1]
+ - [AlphaFold 3.0.2, AlphaFold/3.0.2]
+
+ alphafold_db_module:
+ widget: dependent_module_select
+ label: AlphaFold Database Module
+ driver: alphafold_module
+ options:
+ - prefix: AlphaFold/2.
+ module: AlphaFold2DB
+ - prefix: AlphaFold/3.
+ module: AlphaFold3DB
+
+script: |
+ module load #{alphafold_module}
+ module load #{alphafold_db_module}
+
+ この例では、driverでAlphaFold/2.3.2を選択するとAlphaFold2DBの利用可能なバージョンが読み込まれ、AlphaFold/3.0.0、AlphaFold/3.0.1、AlphaFold/3.0.2のいずれかを選択するとAlphaFold3DBのバージョンが読み込まれます。
+ 接頭辞は、ドロップダウンに表示されるラベルではなく、選択肢の値(AlphaFold/2.3.2など)に対して判定されることに注意してください。
+
+
+ 下記の例では、driverの値を区別する部分が文字列の先頭にないため、代わりにcontains:を使用しています。
+ 値に-gpuを含むCUDAのバージョンはcuDNN-GPUを選択し、それ以外は最後の項目に到達します。最後の項目は照合方法を持たないため、既定値として機能します。
+
form:
+ cuda_module:
+ widget: select
+ label: CUDA Module
+ options:
+ - [CUDA 11.8, CUDA/11.8.0 ]
+ - [CUDA 12.0 (GPU), CUDA/12.0.0-gpu ]
+ - [CUDA 12.3 (GPU), CUDA/12.3.0-gpu ]
+
+ cudnn_module:
+ widget: dependent_module_select
+ label: cuDNN Module
+ driver: cuda_module
+ options:
+ - contains: -gpu
+ module: cuDNN-GPU
+ - module: cuDNN
+
+script: |
+ module load #{cuda_module}
+ module load #{cudnn_module}
+
+
関数zeropadding(key, digit)は数値に対してゼロパディングを行います。第2引数digitに指定した桁数に満たない場合、不足分を「0」で埋めます。
| Widget | label, value, help, required, indent | options | size | separator | direction | min, max, step |
+ Widget | label, value, help, required, indent | options | size | separator | direction | min, max, step |
show_files, favorites |
|---|
| Item name | Setting | Default value |
|---|---|---|
| apps_dir | Application directory | (None) |
| scheduler | Job scheduler (slurm, pbspro, sge, fujitsu_tcs) | (None) |
| clusters | Cluster properties | (None) |
| data_dir | Directory where submitted job information is stored | ${HOME}/composer |
| login_node | Login node when you launch the Open OnDemand web terminal | (None) |
| scheduler | Job scheduler (slurm, pbspro, miyabi, sge, fujitsu_tcs) | (None) |
+ How Open Composer reaches the job scheduler: where the scheduler commands live, and whether they run on the web node or over SSH on a login node. Everything here is site-specific and has no default, so a site whose scheduler commands are on the web node and on PATH can leave all of it unset. Four of these settings have sections of their own: 2.1, 2.2, 2.3 and 2.4.
+
| Item name | Setting | Default value |
|---|---|---|
| clusters | Cluster properties (see section 2.1) | (None) |
| login_node | Hostname of the login node. Used for the "Shell Access" link in the navigation bar, for the terminal shortcut beside the script location on the History page and the application page, and by application forms that shell out to the login node (for example the sacctmgr query that populates the Project dropdown in apps/SlurmBasic). The two page shortcuts are omitted when this is unset, but the navigation bar link is not — see show_shell_access | (None) |
| ssh_wrapper | Command for using the job scheduler of another node using SSH | (None) |
| bin | PATH of commands of job scheduler | (None) |
| bin_overrides | PATH of each command of job scheduler | (None) |
| scheduler_env | Environment variables added when running job scheduler commands | (None) |
| copy_environment | Whether Slurm submits jobs with the PUN environment copied | false |
| sge_root | Directory for the Grid Engine root (SGE_ROOT) | (None) |
| history | Additional display fields on the history page | OC_HISTORY_JOB_NAME, OC_HISTORY_PARTITION, OC_HISTORY_SUBMISSION_TIME |
| footer | Text in the footer | (None) |
| bin | Directory holding the job scheduler commands. It is honored only when <bin>/<command> exists on the machine running Open Composer; when that file is absent the bare command name is used instead and resolved through PATH. In the common ssh_wrapper deployment the commands actually run on the remote host, so the local existence check fails and bin is silently ignored. Use bin_overrides for that case — it is applied unconditionally, with no existence check | (None) |
| bin_overrides | PATH of each command of job scheduler (see section 2.2) | (None) |
| scheduler_env | Environment variables added when running job scheduler commands (see section 2.3) | (None) |
| copy_environment | Whether Slurm submits jobs with the PUN environment copied (see section 2.4) | false |
| sge_root | Value assigned to SGE_ROOT for Grid Engine commands. It is exported on every request — the History table, the Nodes page and the job details modal as well as submission and cancellation — but only when SGE_ROOT is not already set in the environment, so a value inherited by the PUN always wins | (None) |
+ When ensure_ssh_key is true, pressing Submit makes Open Composer check the user's ~/.ssh directory before the job is submitted, and provision a key if none is present. This is intended for sites where jobs are submitted over SSH to a login node that shares the user's home directory.
+
+ The check creates ~/.ssh if it is missing and sets its mode to 0700 in either case, then looks for any of id_ed25519, id_rsa, id_ecdsa, id_dsa, or <ssh_key_name>_<type> for the types ed25519, rsa, ecdsa and dsa. If any of these exists the check stops immediately: an existing key is never overwritten. Otherwise it:
+
ssh-keygen with an empty passphrase and the comment Open Composer auto-generated key, writing ~/.ssh/<ssh_key_name>_<ssh_key_type> (mode 0600) and its .pub file (mode 0644);~/.ssh/authorized_keys (mode 0600) unless that file already contains it;Host * stanza with an IdentityFile ~/.ssh/<ssh_key_name>_<ssh_key_type> line to ~/.ssh/config (mode 0600) unless the key filename already appears there. The stanza applies to every SSH host, because ssh only offers id_* keys automatically.+ The result is written to the PUN log unless a usable key already existed. A failure is logged but does not block the submission. +
+| Item name | Setting | Default value |
|---|---|---|
| ensure_ssh_key | Run the SSH key check described above when a job is submitted (true or false) | false |
| ssh_key_type | Key type passed to ssh-keygen -t. Accepted values are ed25519, rsa and ecdsa; rsa keys are generated with -b 4096. Any other value is silently replaced with ed25519 | ed25519 |
| ssh_key_name | Base name of the generated key files, which are named <ssh_key_name>_<ssh_key_type>. Characters other than letters, digits, _, . and - are stripped; if nothing remains, opencomposer is used | opencomposer |
+ Where Open Composer keeps its own state, and the optional catalog of environment modules read by the module_load and dependent_module_select widgets and by the automatic GPU badge.
+ The catalog is an external dependency rather than part of Open Composer, so before setting modules_list_url see Network and external dependencies in section 1, which covers the JSON format it must have, the outbound network access the web node needs, how the response is cached, and what happens when the download fails.
+
| Item name | Setting | Default value |
|---|---|---|
| data_dir | Directory where submitted job information is stored | ${HOME}/composer |
| modules_list_url | URL of the JSON catalog of available environment modules, used by the module_load and dependent_module_select widgets and by the automatic GPU badge (see Network and external dependencies in section 1). Empty disables the feature | (None) |
+ Which applications and templates users can reach, and how the script browser is offered to them. +
+| Item name | Setting | Default value |
|---|---|---|
| generic_apps_dir | Directory containing hidden generic apps (e.g. a generic Slurm form) that are not shown in the main app listing but can be linked to directly | ./generic_apps |
| external_reload_app | Subfolder inside generic_apps_dir to open when loading an external (non-OpenComposer) job from the History page | Slurm |
| show_load_script | Show the "Load or Create a Script from Disk" button, which opens the full-page file browser, on the Selected Templates and New Custom Template pages (true or false) | true |
| load_script_label | Label of the "Load or Create a Script from Disk" button. Also used as the heading and page title of the file browser page | Load or Create a Script from Disk |
| new_script_featured_category | Name of the manifest.yml category whose templates are listed first on the All Templates and New Script pages. Matched case-insensitively; the remaining templates follow in alphabetical order | Slurm Submit Templates |
+ What the History page shows, and how much of each job Open Composer stores itself rather than reading it back from the scheduler. The column keys are listed in section 2.5. +
+| Item name | Setting | Default value |
|---|---|---|
| history | Additional display fields on the history page (see section 2.5). If this setting is omitted, all seven special variables are shown | OC_HISTORY_JOB_NAME, OC_HISTORY_PARTITION, OC_HISTORY_SUBMISSION_TIME, OC_HISTORY_START_TIME, OC_HISTORY_END_TIME, OC_HISTORY_OUTPUT_FILE, OC_HISTORY_ERROR_FILE |
| history_store_script | Whether to store the full batch script text in the history database. Set to false to always fetch it live via sacct -B | true |
| history_efficiency | Show a Job Efficiency section (Wall Time, CPU, Memory, and GPU where the scheduler recorded it) in the job details modal for completed, failed, and canceled jobs. Uses sacct --json, which requires Slurm 20.11+. Set to true to enable. The GPU Memory percentage also needs gpu_memory below; without it that row shows the amount used but no percentage | false |
| gpu_memory | Memory capacity in GB of each GPU model on the cluster, used only to work out the GPU Memory percentage in the Job Efficiency section. Model names are matched case-insensitively against the job's gpu:<model> resources. Give each model a plain number, or a hash when cards of the same model differ in memory and the scheduler reports them under a single GRES name — an A100 is gpu:a100 whether it holds 40 GB or 80 GB. The hash keys are partition names, plus default for every other partition:
+ gpu_memory: + l4: 23 + h100: 94 + a100: + default: 80 + genoa: 40+ Partition names are matched case-sensitively, as the scheduler's are. Leaving this unset is safe and is the better choice if the capacities are not known locally: GPU memory used is then reported without a percentage, rather than as a percentage of a wrong total. May also be set per-cluster inside clusters | (None) |
+ Checks applied to an application form when the user presses Submit. +
+| Item name | Setting | Default value |
|---|---|---|
| empty_script_warning | Show a confirmation dialog when the user submits a batch script that contains no real commands (only blank lines, comments, #SBATCH directives, and module lines). Set to false to disable. | true |
+ The links, logo, search box, colors and separator of the bar across the top of every page. Each link can be hidden with its show_* setting, and given a different label or icon with the matching *_label and *_icon settings; icons accept either a Font Awesome or a Bootstrap Icons class, as both sets are loaded.
+
| Item name | Setting | Default value |
|---|---|---|
| navbar_color | Background color of navigation bar | #3D3B40 |
| navbar_text_color | Text color of navigation bar | |
| navbar_logo | Filename of a custom logo image to display in the navigation bar (must be placed in public/) | (None) |
| show_navbar_logo | Show the navbar logo (true or false); lets you hide the logo without unsetting navbar_logo | true |
| show_home_directory | Show the "Home Directory" link in the navigation bar (true or false) | true |
| show_shell_access | Show the "Shell Access" link in the navigation bar (true or false). Coupled to login_node: the link is rendered whenever this is true, with no check that login_node is set, and its target is <Open OnDemand>/pun/sys/shell/ssh/<login_node>. With login_node unset the host part of that URL is empty and the link cannot open a shell, so either set login_node or set this to false | true |
| show_open_ondemand | Show the "Open OnDemand" link in the navigation bar (true or false) | true |
| open_ondemand_url | Override for the "Open OnDemand" navigation bar link and the navbar logo link. Leave this unset and both auto-derive to the Open OnDemand dashboard on the host the request arrived on, so no per-site URL is needed. Set it only when the dashboard lives elsewhere | <this host>/pun/sys/dashboard |
| open_ondemand_label | Label text for the "Open OnDemand" navigation bar link | Open OnDemand |
| navbar_search_placeholder | Placeholder text for the navigation bar search box. The box searches every template by name, category and description — including applications hidden from the home page and the user's own saved custom templates — and replaces the page's list with the matches | Search apps… |
| show_search | Show the search box on the right-hand side of the navigation bar (true or false) | true |
| home_directory_label | Label text for the "Home Directory" navigation bar link | Home Directory |
| home_directory_icon | Icon class for the "Home Directory" link. Either a Font Awesome class (e.g. fas fa-folder) or a Bootstrap Icons class (e.g. bi bi-folder-fill); both icon sets are loaded | fas fa-home |
| shell_access_label | Label text for the "Shell Access" navigation bar link | Shell Access |
| shell_access_icon | Icon class for the "Shell Access" link (Font Awesome or Bootstrap Icons) | fas fa-terminal |
| open_ondemand_icon | Icon class for the "Open OnDemand" link (Font Awesome or Bootstrap Icons) | bi bi-grid-fill |
| open_ondemand_new_tab | Open the "Open OnDemand" link and the navbar logo in a new browser tab. Set to false to open them in the same tab | true |
| show_navbar_separator | Horizontal separator rule drawn directly under the navigation bar. Accepted values: false or none for no separator; true or gradient for a 6px gradient rule fading to transparent; solid or line for a 1px solid rule; accent for a 3px colored bar. Any other value is treated as gradient. The separator is never drawn on the All Templates page, which has its own bordered list | false |
| navbar_separator_color | Color of the solid/line and accent separator styles. The gradient style uses a fixed gray and ignores this setting | #C3C8C8 |
+ Colors and layout of everything below the navigation bar. Note that a few of these fall back to the value of another setting rather than to a fixed color, so changing one can affect several; the Default value column shows where that happens. +
+| Item name | Setting | Default value |
|---|---|---|
| home_format | Layout of the home page application grid. big for large tiles (icon + name) or small for compact list-style tiles | big |
| thumbnail_width | Width of thumbnails for each application on the home page | 100 |
| highlight_theme | The theme name for highlight.js used in the script/submit sections | vs |
| directive_color | The text color of scheduler directives in the script/submit sections | #D73A49 |
| navbar_color | Color of navigation bar | #3D3B40 |
| dropdown_color | Color of dropdown menu | |
| footer_color | Color of footer | |
| category_color | Background color of the home page category | #5522BB |
| description_color | Background color of the application description in the application page | |
| accent_color | Accent color used for the Bootstrap overrides in views/layout.erb: links, the primary buttons (Submit, Confirm, Save), the focus ring on inputs and the script editor, ticked checkboxes and radios, and the hover state of the History sort links. Defaults to Bootstrap's own accent, so leaving it unset looks like stock Bootstrap | #0D6EFD |
| accent_contrast_color | Partner to accent_color: used for headings, and for the hover or active state of everything accent_color styles. Should stay legible against white | #0A58CA |
| body_text_color | Default text color of the page body | #212529 |
| highlight_theme | Theme name for highlight.js used in the script/submit sections | vs |
| directive_color | Text color of scheduler directives in the script/submit sections | #D73A49 |
| category_color | Background color of the home page category headers | #5522BB |
| category_text_color | Text color of the home page category headers | |
| description_color | Background color of the band at the top of the application page, which holds the application title, its description and the header fields. Falls back to category_color, so recoloring the home page category headers recolors this band too, unless it is set explicitly | Value of category_color (#5522BB) |
| description_text_color | Text color used on that band — including the header field labels ("Script location", "Script name", "Job name"). Also the fallback for the two settings below | #FFFFFF |
| app_title_color | Color of the application title (the application name shown at the top of the application page). Set this separately when the title needs to differ from the rest of the band — for example because a heading color inherited from the surrounding theme is hard to read against description_color | Value of description_text_color |
| app_description_text_color | Color of the application description shown beneath the title on the application page (taken from description in the app's manifest.yml) | Value of description_text_color |
| form_color | Background color of the text area in the application page | #BFCFE7 |
| non_script_color | Background color of the form that does not affect the script section | #FFE28A |
| non_script_button_color | Background color of buttons that do not affect the script section | #FFBF00 |
| submit_color | Background color of the form that affects only the submit section | #FFCCCC |
| submit_button_color | Background color of buttons that affect only the submit section | #FFAAAA |
| history_action_color | Background color of the "Cancel Job" and "Delete Info" action buttons on the history page | #DC3545 |
| favicon | Filename of the browser tab icon (must be placed in public/). Leave empty to send no favicon link | (None) |
| app_description | Descriptive text shown above the category list on the Selected Templates page. HTML is allowed; it is rendered with description_color and description_text_color. Leave empty to hide it | (None) |
| category_badge_colors | Map of category name to badge background color, used by the All Templates and New Script lists and by the navbar search results. Categories not listed use #6C757D; the "My Template" badge is always #6F42C1 | (None) |
| all_templates_footer | Note shown directly below the All Templates list, above the footer bar. HTML is allowed. Only rendered on the All Templates page, and only when show_footer is true | (None) |
- The apps_dir and scheduler are required. However, the scheduler may be defined inside clusters.
+ The bar across the bottom of every page. Set show_footer: false when embedding Open Composer inside Open OnDemand, so OOD's own footer is used instead.
| Item name | Setting | Default value |
|---|---|---|
| show_footer | Show or hide the footer bar (true or false). Set to false when embedding inside OOD so OOD's own footer is used | true |
| footer | Text or HTML shown in the footer bar. Defaults to a non-breaking space, so an unconfigured footer is still drawn at full height — use show_footer: false to remove the bar entirely | |
| footer_color | Background color of footer. Falls back to navbar_color, so recoloring the navigation bar recolors the footer too, unless this is set explicitly | Value of navbar_color (#3D3B40) |
| footer_text_color | Text color of footer | #FFFFFF |
| footer_padding | Bootstrap padding class applied to the footer bar (e.g. p-1 through p-5) | p-3 |
| footer_ood_logo | Show the bundled Open OnDemand "Powered by" logo in the footer (true or false). Only consulted while footer_brand_logo is unset — a custom brand logo is always shown. Set footer_ood_logo: false and leave footer_brand_logo empty for no footer logo at all | true |
| footer_logo_height | Height of the footer brand logo — either footer_brand_logo, or the bundled Open OnDemand logo when that is unset. Any CSS length | 24px |
| footer_brand_logo | Filename of the "Powered by" brand image shown at the bottom left of the footer (must be placed in public/). When unset, the Open OnDemand logo is used instead unless footer_ood_logo is false | (None) |
| footer_brand_url | URL opened by the footer brand logo | https://openondemand.org/ |
| footer_brand_alt | Alt text of the footer brand logo | Powered by Open OnDemand when the Open OnDemand logo is used, otherwise Powered by |
@@ -105,7 +315,52 @@
+ Set the path for each command. This setting is optional. Unlike bin, an override is used exactly as written, with no check that the file exists, which makes it the setting to use when the commands live on a remote host reached through ssh_wrapper.
+
+ Override only the commands you need; any command left out falls back to bin and then to the bare command name. Note that overriding only the submission command leaves the History and Nodes pages using whatever the PUN's PATH finds.
+
+ If the job scheduler is slurm, the commands used are sbatch (submission), scontrol (job details), scancel (cancellation), sacct (History table, job details, batch script and Job Efficiency), squeue (queued and running jobs added to the History table) and sinfo (Nodes page).
+
bin_overrides: + sbatch: "/usr/local/bin/sbatch" + scontrol: "/usr/local/bin/scontrol" + scancel: "/usr/local/bin/scancel" + sacct: "/usr/local/bin/sacct" + squeue: "/usr/local/bin/squeue" + sinfo: "/usr/local/bin/sinfo"+ +
+ If the job scheduler is pbspro, the commands used are qsub (submission), qstat (job details and History table), qdel (cancellation) and pbsnodes (Nodes page). The miyabi scheduler inherits the PBS Pro class and uses the same command names.
+
bin_overrides: + qsub: "/usr/local/bin/qsub" + qstat: "/usr/local/bin/qstat" + qdel: "/usr/local/bin/qdel" + pbsnodes: "/usr/local/bin/pbsnodes"+ +
+ If the job scheduler is sge, the commands used are qsub (submission), qstat (active jobs), qdel (cancellation), qacct (completed jobs in the History table) and qhost (Nodes page).
+
bin_overrides: + qsub: "/usr/local/bin/qsub" + qstat: "/usr/local/bin/qstat" + qdel: "/usr/local/bin/qdel" + qacct: "/usr/local/bin/qacct" + qhost: "/usr/local/bin/qhost"+ +
+ If the job scheduler is fujitsu_tcs, the commands used are pjsub (submission), pjstat (job details, History table and Nodes page) and pjdel (cancellation).
+
bin_overrides: + pjsub: "/usr/local/bin/pjsub" + pjstat: "/usr/local/bin/pjstat" + pjdel: "/usr/local/bin/pjdel"+ +
Set environment variables added when running job scheduler commands. This setting is optional.
For example, this can be used when SLURM_CONF_SERVER is required for a Slurm configless setup.
@@ -124,8 +379,11 @@
ssh_wrapper is used to run job scheduler commands on a remote host, scheduler_env is applied to the local ssh command.
If the environment variables are also required on the remote side, configure SSH or a wrapper script accordingly.
+
+ Scope. scheduler_env is applied to every scheduler command Open Composer runs, not just job submission: the History table (sacct_all_jobs(), squeue_active_jobs()), the Nodes page (sinfo_nodes()), the job details modal (sacct_job(), scontrol_job()), the Job Efficiency section (efficiency()) and batch script retrieval (batch_script()) all receive it. So a variable such as SLURM_CONF_SERVER, required for a configless Slurm setup, is enough on its own to make every page work.
+
Set this to true to submit Slurm jobs with --export=ALL. The default is false, which keeps the existing behavior of submitting Slurm jobs with --export=NONE.
This setting is only used by Slurm.
@@ -141,57 +399,36 @@
This copies the PUN environment when issuing Slurm commands. Be careful because the PUN environment can be different from a regular login shell environment.
- -- Set the path for each command. This setting is optional. -
-
- If the job scheduler is slurm, set sbatch, scontrol, scancel, and sacct as follows.
-
bin_overrides: - sbatch: "/usr/local/bin/sbatch" - scontrol: "/usr/local/bin/scontrol" - scancel: "/usr/local/bin/scancel" - sacct: "/usr/local/bin/sacct"- -
- If the job scheduler is pbspro, set qsub, qstat, and qdel as follows.
-
bin_overrides: - qsub: "/usr/local/bin/qsub" - qstat: "/usr/local/bin/qstat" - qdel: "/usr/local/bin/qdel"-
- If the job scheduler is sge, set qsub, qstat, qdel, and qacct as follows.
+ The --export flag is only synthesized when the application supplied no submit options of its own. If the application's submit section sets a non-empty OC_SUBMIT_OPTIONS, that string is passed to sbatch as-is and copy_environment is ignored entirely, so such an application must include its own --export=… if it needs one.
bin_overrides: - qsub: "/usr/local/bin/qsub" - qstat: "/usr/local/bin/qstat" - qdel: "/usr/local/bin/qdel" - qacct: "/usr/local/bin/qacct"- -
- If the job scheduler is fujitsu_tcs, set pjsub, pjstat, and pjdel as follows.
-
bin_overrides: - pjsub: "/usr/local/bin/pjsub" - pjstat: "/usr/local/bin/pjstat" - pjdel: "/usr/local/bin/pjdel"
The mandatory fields to be displayed on the history page are "Job ID", "Application", "Script Location", "Script Name", and "Status".
- In addition to these, the history allows you to set additional fields to display.
- If this setting is omitted, "Job Name", "Partition", and "Submission Time" are automatically set.
- This is equivalent to the code shown below.
- OC_HISTORY_JOB_NAME, OC_HISTORY_PARTITION, and OC_HISTORY_SUBMISSION_TIME are special variables that correspond to "Job Name", "Partition", and "Submission Time", respectively.
+ In addition to these, the history setting controls which extra fields appear.
+ If this setting is omitted, all of the special variables are included by default.
+ The available special variables are:
+
| Special variable | Displayed as |
|---|---|
OC_HISTORY_JOB_NAME | Job Name |
OC_HISTORY_PARTITION | Partition — the queue or partition the job ran in |
OC_HISTORY_SUBMISSION_TIME | Submission Time — when the job was submitted |
OC_HISTORY_START_TIME | Start Time — the job start time reported by the scheduler |
OC_HISTORY_END_TIME | End Time — the job end time reported by the scheduler |
OC_HISTORY_OUTPUT_FILE | Output — the scheduler's stdout file for the job. Clicking the filename opens the file content in an overlay panel. |
OC_HISTORY_ERROR_FILE | Error — the scheduler's stderr file for the job. Clicking the filename opens the file content in an overlay panel. |
+ A typical configuration showing job name, start time, and end time with custom labels:
history: OC_HISTORY_JOB_NAME: - OC_HISTORY_PARTITION: - OC_HISTORY_SUBMISSION_TIME:+ OC_HISTORY_START_TIME: + label: "Start Time" + OC_HISTORY_END_TIME: + label: "End Time"
If you want to disable additional display fields, define an empty array. @@ -199,10 +436,15 @@
history: []
- You can set profile values obtained from the job scheduler as display fields.
- Specify in history the value shown in the left column of the table that appears when you click "Job ID".
- By using label, you can define a display label.
- If label is not specified, the profile value is used as is.
+ You can also add fields taken directly from the job scheduler's own accounting output. A key in history that is not one of the OC_HISTORY_* variables above is looked up verbatim in the record that the scheduler class's sacct_all_jobs() method returned for that job, so only the field names that method actually requests produce a value; any other name gives an empty column. The lookup is an exact hash lookup, so the name is case-sensitive and must be spelled as shown below. Note that the longer field list shown in the modal that opens when you click "Job ID" comes from a different command, and most of those names do not work here.
+
+ For slurm the usable names are
+ JobID, JobName, Partition, State, Submit, Start, End, Elapsed, WorkDir, Account, TotalCPU, AllocCPUS, ReqMem, ExitCode, NodeList, StdOut, StdErr and SubmitLine.
+ Any field the local Slurm build does not support is dropped. For the other schedulers the usable names are the keys their own sacct_all_jobs() builds — see lib/schedulers/.
+
+ Use label to set the column heading; without it the field name is used as the heading.
history: @@ -215,11 +457,11 @@-2.5. history
3. Registration
When you save Open Composer to
/var/www/ood/apps/sys/, the Open Composer icon will be displayed on the Open OnDemand home page. -If it is not displayed, check/var/www/ood/apps/sys/OpenComposer/manifest.yml. +If it is not displayed, check/var/www/ood/apps/sys/opencomposer/manifest.yml.You can also display Open Composer applications on the Open OnDemand home page. - For example, if you want to display an application
@@ -227,9 +469,129 @@/var/www/ood/apps/sys/OpenComposer/sample_apps/Slurm, + For example, if you want to display an application/var/www/ood/apps/sys/opencomposer/sample_apps/Slurm, create a directory with the same name in the Open OnDemand application directory (# mkdir /var/www/ood/apps/sys/Slurm). Then, create the following Open OnDemand configuration filemanifest.ymlin that directory.3. Registration
# /var/www/ood/apps/sys/Slurm/manifest.yml --- name: Slurm -url: https://<your Open OnDemand URL>/pun/sys/OpenComposer/Slurm+url: https://<your Open OnDemand URL>/pun/sys/opencomposer/Slurm
+ By default, clicking the Open Composer tile in Open OnDemand opens the application in a new tab.
+ The files in ood_integration/ enable an embedded mode where Open Composer is rendered directly inside the OOD page — OOD's real navigation bar stays at the top, Open Composer fills the middle, and OOD's own footer is shown at the bottom. The user never leaves the OOD interface.
+
+ The page is a single document rendered in OOD's own dashboard layout, so the header and footer are OOD's live chrome — dynamic menus, user/help dropdowns and notifications — and no Content-Security-Policy changes are needed. +
+
+ This requires Open OnDemand 3.x or later and administrator access to /etc/ood/config/.
+
+ The initializer opencomposer_embed.rb mounts a small reverse-proxy controller inside the OOD dashboard at /pun/sys/dashboard/oc and intercepts the Open Composer tile so it lands there. For each request the proxy:
+
/pun/sys/opencomposer/… over the loopback through Apache (on the same port the browser used), forwarding the user's session cookie so the call is authenticated as that user./pun/sys/opencomposer → /pun/sys/dashboard/oc in every text response, so all links, form actions, assets and AJAX stay on the proxy path — every page therefore stays wrapped in OOD's chrome.<head> assets and <body> into the dashboard's layout via opencomposer_embed.html.erb, giving the live OOD navbar and footer. CSS/JS are streamed through (prefix-rewritten); images and fonts pass through unchanged; redirects are relayed with their Location rewritten onto the proxy path.$ cd /var/www/ood/apps/sys/ +$ sudo git clone https://github.com/RIKEN-RCCS/OpenComposer.git opencomposer+ +
+ Open Composer will install its Ruby gem dependencies automatically the first time a user opens the app. + To avoid users seeing a loading delay on that first visit, you can pre-install the gems as the administrator: +
+$ cd /var/www/ood/apps/sys/opencomposer +$ sudo cp misc/Gemfile . +$ sudo bundle install+
+ Re-run bundle install after any git pull that updates the Gemfile.
+
$ cd /var/www/ood/apps/sys/opencomposer +$ sudo cp conf.yml.erb.sample conf.yml.erb+
+ For OOD-integrated mode, set the following in conf.yml.erb to avoid duplicating UI elements that OOD already provides:
+
show_home_directory: false # OOD's Files menu links to the home directory +show_shell_access: false # OOD's Clusters menu provides shell access +show_open_ondemand: false # No need to link back to OOD from inside OOD +navbar_logo: ~ # OOD's navbar already shows the site logo +show_footer: false # OOD's footer is shown below the embedded view+ +
+ Add new_window: false to manifest.yml so clicking the tile stays in the same tab instead of opening a new window:
+
# /var/www/ood/apps/sys/opencomposer/manifest.yml +name: Open Composer +category: Jobs +description: | + Open Composer is an application that creates and submits batch job scripts. +icon: fas://hat-wizard +new_window: false+ +
$ sudo mkdir -p /etc/ood/config/apps/dashboard/initializers +$ sudo mkdir -p /etc/ood/config/apps/dashboard/views/apps + +$ sudo cp /var/www/ood/apps/sys/opencomposer/ood_integration/initializers/opencomposer_embed.rb \ + /etc/ood/config/apps/dashboard/initializers/ + +$ sudo cp /var/www/ood/apps/sys/opencomposer/ood_integration/views/apps/opencomposer_embed.html.erb \ + /etc/ood/config/apps/dashboard/views/apps/+ +
In the OOD dashboard: Help → Restart Web Server, or from the command line:
+$ sudo httpd -k graceful+
+ Clicking the Open Composer tile will now open it embedded within OOD's page. +
+ +
+ The integration uses only standard OOD mechanisms (a dashboard initializer and the normal /pun request flow) and is multi-user-safe — each request forwards the requesting user's own session cookie, so Apache authenticates and routes to that user's instance. It should port to other Open OnDemand sites, but a few environment assumptions are worth checking. Overrides are read from the dashboard's env file /etc/ood/config/apps/dashboard/env; a fully commented template is provided at ood_integration/dashboard.env.example:
+
| Assumption | If your site differs |
|---|---|
Open Composer is installed as the sys app opencomposer (i.e. served at /pun/sys/opencomposer). |
+ Set OC_EMBED_APP_NAME to your install directory name (for example OpenComposer). |
+
| OOD's Apache (the portal vhost) is reachable on the loopback at the same port/scheme the browser used — true for a standard host serving HTTPS on 443. | +If a TLS-terminating load balancer fronts OOD and the portal vhost actually listens on a different port/scheme, set OC_EMBED_UPSTREAM_HOST, OC_EMBED_UPSTREAM_PORT, OC_EMBED_UPSTREAM_SCHEME (http/https) and/or OC_EMBED_UPSTREAM_IP accordingly. |
+
Authentication is mod_auth_openidc; its session cookie is sent to the dashboard on /pun (the stock ood-portal.conf only strips it on /node and /rnode). |
+ If your site uses a different auth module or strips cookies more aggressively, confirm the dashboard still receives the auth cookie so the proxy's upstream call is authenticated. | +
You may install a custom Rails initializer under /etc/ood/config/apps/dashboard/initializers/. |
+ Managed/locked-down deployments may not permit this, or may require a security review (the initializer makes a server-side HTTP call). Confirm with the facility's OOD administrators. | +
+ Performance note. Every Open Composer response — including CSS, JS, images and fonts — is proxied through the dashboard Ruby process. This is fine for typical interactive use; if you expect heavy concurrent load, account for the extra dashboard traffic. +
+ ++ Remove the two integration files and reload Apache: +
+$ sudo rm /etc/ood/config/apps/dashboard/initializers/opencomposer_embed.rb +$ sudo rm /etc/ood/config/apps/dashboard/views/apps/opencomposer_embed.html.erb +$ sudo httpd -k graceful+
+ After this, clicking the tile will open Open Composer as a full-page app in the same browser tab (because new_window: false is still set in manifest.yml).
+ If you also want to restore the original new-tab behavior, remove or revert that line:
+
# /var/www/ood/apps/sys/opencomposer/manifest.yml +new_window: true # or remove the line entirely — true is the OOD default+ +
You can also install Open Composer with general user privileges. However, the App Development feature in Open OnDemand needs to be enabled in advance by an administrator. @@ -255,7 +617,7 @@
- The procedure for starting Open Composer locally is as follows:
@@ -270,7 +632,7 @@
misc/tests/run_tests.rb is a smoke test that verifies every form.yml in the documentation and the sample applications is processed correctly. Run it as follows:
form section passes the same validations as run.rb,node --check; skipped if node is not installed).node --check, falling back to macOS's bundled jsc; skipped if neither is available).If all samples pass, it exits with code 0 and prints the following. If any sample fails, its name and cause are shown and the exit code is 1.
---------------------------------------- -42/42 samples passed+44/44 samples passed
These are smoke tests: they guarantee that every sample builds without errors, but they do not cover browser-side behavior (such as operating a widget and observing the effect of the Dynamic Form Widget). Verify that layer in a real browser.
-
- If you want to add a job scheduler, create a Ruby script for the job scheduler under lib/schedulers/ using the superclass Scheduler defined in lib/scheduler.rb as a reference. Inherit the Scheduler class as shown in the PBS Pro example below (lib/schedulers/pbspro.rb).
- You must define the submit() method for submitting a job, the cancel() method for canceling a job, and the query() method for querying job information.
+ If you want to add a job scheduler, create a Ruby script for it under lib/schedulers/ that subclasses the Scheduler class defined in lib/scheduler.rb, as PBS Pro does in lib/schedulers/pbspro.rb.
class Pbspro < Scheduler
- Also, in some clusters, job scheduler commands (e.g., qstat) are wrapper scripts, making it impossible for users to execute the original commands. In such cases, you may be able to address this issue by making minor changes to the existing scheduler script. For example, in lib/schedulers/miyabi.rb, a new class, Miyabi, is defined by inheriting the PBS Pro scheduler, as shown below. The Miyabi class defines only the query() method, while the other methods use those defined in lib/schedulers/pbspro.rb.
+ Scheduler declares submit(), cancel() and query() as abstract, and supplies a working but empty default for every other hook. Because those defaults never fail, a class that implements only submission and cancellation will submit and cancel jobs while the History and Nodes pages stay silently empty. The hooks are:
+
| Method | What it drives | If not overridden |
|---|---|---|
submit() | Job submission from an application page | Must be implemented |
cancel() | "Cancel Job" on the history page | Must be implemented |
query() | Part of the superclass interface; job state on the history page comes from sacct_all_jobs() instead | Must be implemented if it is ever called |
sacct_all_jobs() | The entire history page. It is the sole source of which jobs exist, and of their state, times, working directory and stdout/stderr paths | Returns nothing, so the history page always shows "(No Jobs)" |
state_to_oc_status() | Maps the scheduler's raw state strings onto the Queued / Running / Completed / Cancelled / Failed badges | Every job is reported with unknown status |
valid_job_id?() | Decides which job IDs from the scheduler are accepted into the history table | Only all-digit IDs are accepted, so array-job and other composite IDs are silently dropped |
sinfo_nodes() | The nodes page. Returns one array per node: name, state, CPUs (allocated/idle/other/total), memory, free memory, generic resources, generic resources in use | The nodes page shows no rows |
sacct_job() and scontrol_job() | The job details modal opened by clicking a job ID — the accounting record and the live record respectively | Optional. The modal reports that no details are available |
batch_script() | Fetching the submitted script back from the scheduler. Used by the job script view, and required when history_store_script is false | Optional. No script is shown for jobs whose script is not in the history database |
squeue_active_jobs() | Supplements sacct_all_jobs() with queued and running jobs the accounting command has not reported yet. Must return the same key names as sacct_all_jobs() | Optional. Freshly submitted jobs may be missing from the history page until accounting catches up |
squeue_start_times() | Estimated start times for pending jobs. Declared on Scheduler for completeness; like query(), no current code path calls it | Optional; nothing depends on it today |
efficiency() | The Job Efficiency section, when history_efficiency is true | Optional. The section reports that efficiency is not supported by this scheduler |
+ Every hook receives bin, bin_overrides, ssh_wrapper and scheduler_env as its trailing arguments. Run each command through the inherited capture_scheduler_command(scheduler_env, command) helper rather than calling Open3.capture3 directly, so that scheduler_env (see section 2.3) is honored.
+
+ Also, in some clusters, job scheduler commands (e.g., qstat) are wrapper scripts, making it impossible for users to execute the original commands. In such cases, you may be able to address this issue by making minor changes to an existing scheduler script. For example, lib/schedulers/miyabi.rb defines a Miyabi class that inherits the PBS Pro scheduler and overrides just two methods, query() and sacct_all_jobs(), because Miyabi needs a site-specific qstat -H --hday form for completed jobs. Every other method comes from lib/schedulers/pbspro.rb.
class Miyabi < Pbspro
After creating the job scheduler script, specify the scheduler in ./conf.yml.erb as shown below.
scheduler: miyabi+ diff --git a/docs/install_ja.html b/docs/install_ja.html index 959f6f43..11dc5627 100644 --- a/docs/install_ja.html +++ b/docs/install_ja.html @@ -16,15 +16,16 @@
Open ComposerはOpen OnDemand上で動作します。Open OnDemandのアプリケーションディレクトリ/var/www/ood/apps/sys/にOpen Composerを保存してください。
+ ここにインストールしたアプリケーションは、ユーザ毎の設定を必要とせず、そのOpen OnDemandのすべてのユーザが自動的に利用できるようになります。
$ cd /var/www/ood/apps/sys/ -$ sudo git clone https://github.com/RIKEN-RCCS/OpenComposer.git+$ sudo git clone https://github.com/RIKEN-RCCS/OpenComposer.git opencomposer +
+ ディレクトリ名はアプリケーションのURLの一部になります(/pun/sys/opencomposer)。また、後述する4. OOD統合インストールのOOD統合モードを有効にする場合にも影響します。そのプロキシは既定でopencomposerを対象とするため、別の名前でインストールした場合は、それに合わせてOC_EMBED_APP_NAMEを設定してください。
+
+ Open Composerは、ユーザが最初にアプリケーションを開いたときに、依存するRubyのgemを自動的にインストールします。 + その初回のアクセスでユーザが待たされることを避けるため、管理者が事前にgemをインストールしておくことができます。 +
++$ cd /var/www/ood/apps/sys/opencomposer +$ sudo cp misc/Gemfile . +$ sudo bundle install+
+ Gemfileが更新されるgit pullを行った後は、bundle installを再度実行してください。
+
+ module_loadウィジットとdependent_module_selectウィジット、および自動的に付与されるGPUのバッジは、クラスタで利用可能なモジュールのカタログによって動作します。Open Composerは、conf.yml.erbのmodules_list_urlで指定されたURLからそれを取得します。この設定はデフォルトでは空であり、その場合この機能は動作しません。モジュールのウィジットはバージョンを提示せず、GPUのバッジも自動的には付与されません。それ以外の機能には影響しません。
+
+ この設定を行う場合、Passengerのアプリケーション(PUN)から、そのホストへの外向きのネットワークアクセスが必要です。取得する文書は次の形式のJSONでなければなりません。 +
+{
+ "GROMACS": {
+ "versions": ["2025.2-foss-2023a", "2024.5-foss-2023a"],
+ "default": "2025.2-foss-2023a",
+ "domains": ["chem"]
+ }
+}
+
+ domainsの一覧にgpuを含むモジュールは、同名のアプリケーションに自動的にGPUのバッジを付与します。アプリケーションは、manifest.ymlのtagsキーで明示的にバッジを付与することもできます。
+
+ この一覧はページの描画中に取得されます。Open Composerのすべてのページで参照が発生し、モジュールのウィジットが行う/_module_availの要求でも発生します。
+ 応答は<data_dir>/.module-list-cache.jsonにキャッシュされ、キャッシュのファイルが24時間より古くなった場合にのみ再取得されます。
+ 接続のタイムアウトは10秒、読み込みのタイムアウトは15秒です。取得に失敗した場合、既存の(古い)キャッシュのファイルが使用されます。キャッシュのファイルが無い場合、一覧は空として扱われます。ユーザにはエラーが表示されないため、ウィジットが空のままになる場合はPUNのログを確認してください。
+
+ Open Composerは、実行したジョブスケジューラの操作毎に、標準出力へログの行を書き出します。
+ Open OnDemandのPassengerは標準出力をユーザ毎のPUNのログ/var/log/ondemand-nginx/<user>/error.logに取り込むため、ジョブの投入が期待どおりに動作しない場合は、このファイルを確認してください。
+ このパスにアプリケーション毎の要素が無いことに注意してください。ユーザ毎にPUNは1つであり、そのユーザが開くすべてのOpen OnDemandのアプリケーション(ダッシュボードを含む)が同じファイルに書き出します。
+ Open Composerが出力する各行は次の形式です。
+
[<time>] [Open Composer] <action> : scheduler=<scheduler class> : <key>=<value> : ...+
+ Passengerは取り込んだすべての行の先頭にApp <pid> output:を付加するため、上記のテキストは行の先頭ではなく途中に現れます。
+ これらの記録を要求のログや他のアプリケーションのログと区別するには、[Open Composer]のタグで絞り込んでください。
+ その際は固定文字列としての一致を用いてください。-Fを付けないと角括弧が文字クラスとして解釈され、すべての行が一致してしまいます。
+
$ sudo grep -F '[Open Composer]' /var/log/ondemand-nginx/<user>/error.log+
+ 末尾のキーと値の組は操作によって異なり、該当する場合にcluster、job_ids、app_dir、app_name、category、script_path、command、resultが含まれます。空の値は省略されます。記録される操作は次のとおりです。
+
Submit jobとSave job fileCancel job、Cancel all jobs、Delete job information、Delete all job historyRun commands in the check sectionとRun commands in the submit section(実行したコマンドも記録されます)Ensure SSH key — 実際に鍵が作成された場合、または生成に失敗した場合にのみ記録され、利用可能な鍵がすでに存在した場合は記録されません
- ./conf.yml.erb.sampleを参考にして./conf.yml.erbを作成してください。
+ ./conf.yml.erb.sampleを参考にして./conf.yml.erbを作成してください。このサンプルにはすべての設定項目がデフォルト値とともに記載されているため、項目毎に本文書を参照することなく、そのまま編集できます。
$ cd OpenComposer +$ cd opencomposer $ sudo cp conf.yml.erb.sample conf.yml.erb++ 下記の分類は
+conf.yml.erb.sampleの番号付きの節と同じ順序で並んでいるため、ファイルと本文書を並べて読むことができます。 + Open Composerを動作させるために設定が必要なものから、保存・表示される内容、そして外観に関するものへと並んでいます。値の設定が必須なのは必須の2項目のみです。 +1. 必須
+
apps_dirとschedulerは必須です。schedulerはclustersの中にクラスタ毎に定義しても構いません。
| 項目名 | 設定内容 | デフォルト値 |
|---|---|---|
| apps_dir | アプリケーションのディレクトリ | (None) |
| scheduler | 利用するスケジューラ(slurm、pbspro、sge、fujitsu_tcs) | (None) |
| clusters | クラスタの定義 | (None) |
| data_dir | 投入したジョブの情報の保存先 | ${HOME}/composer |
| login_node | Open OnDemandのWebターミナルを起動した際のログイン先 | (None) |
| scheduler | ジョブスケジューラ(slurm、pbspro、miyabi、sge、fujitsu_tcs) | (None) |
+ Open Composerがジョブスケジューラに到達する方法、すなわちスケジューラのコマンドが置かれている場所と、それをWebノード上で実行するのかログインノード上でSSH経由で実行するのかを設定します。ここにある項目はすべてサイト固有であり、デフォルト値はありません。そのため、スケジューラのコマンドがWebノード上にありPATHに含まれているサイトでは、すべて未設定のままで構いません。このうち4つの項目には独立した節があります(2.1、2.2、2.3、2.4)。
+
| 項目名 | 設定内容 | デフォルト値 |
|---|---|---|
| clusters | クラスタの定義(2.1. clustersを参照) | (None) |
| login_node | ログインノードのホスト名。ナビゲーションバーの「Shell Access」のリンク、履歴ページとアプリケーションページのスクリプトの保存先の横にあるターミナルのショートカット、およびログインノードでコマンドを実行するアプリケーションのフォーム(例えばapps/SlurmBasicで「Project」のドロップダウンを生成するsacctmgrの問い合わせ)で使用されます。未設定の場合、2つのページのショートカットは表示されませんが、ナビゲーションバーのリンクは表示されます(show_shell_accessを参照) | (None) |
| ssh_wrapper | SSHを用いて他のノードのジョブスケジューラを用いる場合のコマンド | (None) |
| bin | ジョブスケジューラのコマンドのパス | (None) |
| bin_overrides | ジョブスケジューラの各コマンドのパス | (None) |
| scheduler_env | ジョブスケジューラのコマンド実行時に追加する環境変数 | (None) |
| copy_environment | Slurmのジョブ投入時にPUNの環境変数をコピーするかどうか | false |
| sge_root | Grid Engineのルート用ディレクトリ(SGE_ROOT) | (None) |
| history | 履歴ページの追加表示項目 | OC_HISTORY_JOB_NAME, OC_HISTORY_PARTITION, OC_HISTORY_SUBMISSION_TIME |
| footer | フッタに記載する文字 | (None) |
| bin | ジョブスケジューラのコマンドが置かれているディレクトリ。Open Composerが動作しているマシン上に<bin>/<command>が存在する場合にのみ有効です。そのファイルが存在しない場合は、コマンド名のみが使用され、PATHから解決されます。ssh_wrapperを用いる一般的な構成では、コマンドは実際にはリモートホスト上で実行されるため、ローカルでの存在確認は失敗し、binは無視されます。その場合はbin_overridesを使用してください。こちらは存在確認を行わず、常に適用されます | (None) |
| bin_overrides | ジョブスケジューラの各コマンドのパス(2.2. bin_overridesを参照) | (None) |
| scheduler_env | ジョブスケジューラのコマンド実行時に追加する環境変数(2.3. scheduler_envを参照) | (None) |
| copy_environment | Slurmのジョブ投入時にPUNの環境変数をコピーするかどうか(2.4. copy_environmentを参照) | false |
| sge_root | Grid Engineのコマンドに対してSGE_ROOTとして設定される値。ジョブの投入とキャンセルだけでなく、履歴のテーブル、ノードページ、ジョブの詳細のモーダルを含むすべての要求で設定されます。ただし、環境にSGE_ROOTがまだ設定されていない場合にのみ設定されるため、PUNが継承している値が常に優先されます | (None) |
+ ensure_ssh_keyがtrueの場合、「Submit」を押すと、Open Composerはジョブを投入する前にユーザの~/.sshディレクトリを確認し、鍵が存在しなければ鍵を用意します。これは、ユーザのホームディレクトリを共有しているログインノードへSSHでジョブを投入するサイトを想定した機能です。
+
+ この確認では、~/.sshが存在しない場合はそれを作成し、いずれの場合もそのモードを0700に設定します。次に、id_ed25519、id_rsa、id_ecdsa、id_dsa、およびed25519、rsa、ecdsa、dsaの各種類についての<ssh_key_name>_<type>を探します。これらのいずれかが存在する場合、確認は直ちに終了します。既存の鍵が上書きされることは決してありません。存在しない場合は、次の処理を行います。
+
Open Composer auto-generated keyとしてssh-keygenを実行し、~/.ssh/<ssh_key_name>_<ssh_key_type>(モード0600)とその.pubファイル(モード0644)を書き出します。~/.ssh/authorized_keys(モード0600)に、その公開鍵がまだ含まれていない場合に追記します。~/.ssh/config(モード0600)に、その鍵のファイル名がまだ現れていない場合、IdentityFile ~/.ssh/<ssh_key_name>_<ssh_key_type>の行を含むHost *のブロックを追記します。sshが自動的に提示するのはid_*の鍵のみであるため、このブロックはすべてのSSHのホストを対象とします。+ 利用可能な鍵がすでに存在した場合を除き、結果はPUNのログに書き出されます。失敗した場合も記録されますが、ジョブの投入は妨げられません。 +
+| 項目名 | 設定内容 | デフォルト値 |
|---|---|---|
| ensure_ssh_key | ジョブの投入時に上記のSSH鍵の確認を行うかどうか(trueまたはfalse) | false |
| ssh_key_type | ssh-keygen -tに渡す鍵の種類。ed25519、rsa、ecdsaを指定できます。rsaの鍵は-b 4096で生成されます。それ以外の値はed25519に置き換えられます | ed25519 |
| ssh_key_name | 生成される鍵のファイルの基本名。ファイル名は<ssh_key_name>_<ssh_key_type>になります。英数字、_、.、-以外の文字は除去され、何も残らない場合はopencomposerが使用されます | opencomposer |
+ Open Composer自身の状態を保存する場所と、module_loadウィジットおよびdependent_module_selectウィジット、ならびに自動的に付与されるGPUのバッジが読み込む、任意の環境モジュールのカタログを設定します。
+ このカタログはOpen Composerの一部ではなく外部への依存であるため、modules_list_urlを設定する前に、1章のネットワークと外部への依存を参照してください。そこでは、必要なJSONの形式、Webノードに必要な外向きのネットワークアクセス、応答のキャッシュ方法、取得に失敗した場合の動作を説明しています。
+
| 項目名 | 設定内容 | デフォルト値 |
|---|---|---|
| data_dir | 投入したジョブの情報の保存先 | ${HOME}/composer |
| modules_list_url | 利用可能な環境モジュールのカタログのJSONのURL。module_loadウィジットとdependent_module_selectウィジット、および自動的に付与されるGPUのバッジで使用されます(1章のネットワークと外部への依存を参照)。空の場合、この機能は無効になります | (None) |
+ ユーザが到達できるアプリケーションとテンプレート、およびスクリプトのファイルブラウザの提示方法を設定します。 +
+| 項目名 | 設定内容 | デフォルト値 |
|---|---|---|
| generic_apps_dir | アプリケーションの一覧には表示されないが直接リンクできる、非表示の汎用アプリケーション(例えば汎用のSlurmのフォーム)を格納するディレクトリ | ./generic_apps |
| external_reload_app | 履歴ページからOpen Composer以外で投入されたジョブを読み込むときに開く、generic_apps_dir内のサブフォルダ | Slurm |
| show_load_script | 全画面のファイルブラウザを開く「Load or Create a Script from Disk」ボタンを、「Selected Templates」と「New Custom Template」のページに表示するかどうか(trueまたはfalse) | true |
| load_script_label | 「Load or Create a Script from Disk」ボタンのラベル。ファイルブラウザのページの見出しとページタイトルにも使用されます | Load or Create a Script from Disk |
| new_script_featured_category | 「All Templates」と「New Script」のページで先頭に表示するテンプレートの、manifest.ymlのカテゴリ名。大文字と小文字を区別せずに照合され、残りのテンプレートはアルファベット順で続きます | Slurm Submit Templates |
+ 履歴ページに表示する内容と、ジョブスケジューラから読み直すのではなくOpen Composer自身がどこまで保存するかを設定します。列のキーは2.5. historyに一覧があります。 +
+| 項目名 | 設定内容 | デフォルト値 |
|---|---|---|
| history | 履歴ページの追加表示項目(2.5. historyを参照)。この設定を省略した場合、7つの特殊な変数すべてが表示されます | OC_HISTORY_JOB_NAME, OC_HISTORY_PARTITION, OC_HISTORY_SUBMISSION_TIME, OC_HISTORY_START_TIME, OC_HISTORY_END_TIME, OC_HISTORY_OUTPUT_FILE, OC_HISTORY_ERROR_FILE |
| history_store_script | バッチスクリプトの全文を履歴のデータベースに保存するかどうか。falseにすると、常にsacct -Bで取得します | true |
| history_efficiency | 完了、失敗、キャンセルされたジョブについて、ジョブの詳細のモーダルにJob Efficiencyの区画(Wall Time、CPU、Memory、およびジョブスケジューラが記録している場合はGPU)を表示します。sacct --jsonを使用するため、Slurm 20.11以降が必要です。有効にするにはtrueを設定します。GPU Memoryの百分率には、下記のgpu_memoryも必要です。設定していない場合、その行には使用量のみが表示され、百分率は表示されません | false |
| gpu_memory | クラスタ上の各GPUのモデルのメモリ容量(GB)。Job Efficiencyの区画のGPU Memoryの百分率を算出するためにのみ使用されます。モデル名は、ジョブのgpu:<model>のリソースと大文字・小文字を区別せずに照合されます。各モデルには単純な数値を指定します。同じモデルのカードでメモリ容量が異なり、かつジョブスケジューラがそれらを1つのGRESの名前で報告する場合は、ハッシュを指定します。A100は40 GBでも80 GBでもgpu:a100として報告されます。ハッシュのキーはパーティション名であり、それ以外のすべてのパーティションのためにdefaultを指定します。
+ gpu_memory: + l4: 23 + h100: 94 + a100: + default: 80 + genoa: 40+ パーティション名は、ジョブスケジューラと同様に大文字と小文字を区別して照合されます。容量が分からない場合は、未設定のままにする方が安全であり適切です。その場合、GPUのメモリの使用量は百分率なしで報告されるため、誤った総量に対する百分率が表示されることはありません。 clustersの中にクラスタ毎に設定することもできます | (None) |
+ ユーザが「Submit」を押したときに、アプリケーションのフォームに対して行われる確認を設定します。 +
+| 項目名 | 設定内容 | デフォルト値 |
|---|---|---|
| empty_script_warning | 実際のコマンドを含まない(空行、コメント、#SBATCHのディレクティブ、moduleの行のみからなる)バッチスクリプトを投入したときに、確認のダイアログを表示します。無効にするにはfalseを設定します | true |
+ すべてのページの上部にあるバーのリンク、ロゴ、検索ボックス、色、区切り線を設定します。各リンクは対応するshow_*で非表示にでき、対応する*_labelと*_iconでラベルとアイコンを変更できます。アイコンにはFont AwesomeのクラスとBootstrap Iconsのクラスのどちらも指定できます。両方のアイコンセットが読み込まれています。
+
| 項目名 | 設定内容 | デフォルト値 |
|---|---|---|
| navbar_color | ナビゲーションバーの背景色 | #3D3B40 |
| navbar_text_color | ナビゲーションバーの文字色 | |
| navbar_logo | ナビゲーションバーに表示するロゴの画像のファイル名(public/に配置する必要があります) | (None) |
| show_navbar_logo | ナビゲーションバーのロゴを表示するかどうか(trueまたはfalse)。navbar_logoの値を消さずにロゴを非表示にできます | true |
| show_home_directory | ナビゲーションバーに「Home Directory」のリンクを表示するかどうか(trueまたはfalse) | true |
| show_shell_access | ナビゲーションバーに「Shell Access」のリンクを表示するかどうか(trueまたはfalse)。login_nodeと関係します。この設定がtrueであれば、login_nodeが設定されているかを確認せずにリンクが描画され、その参照先は<Open OnDemand>/pun/sys/shell/ssh/<login_node>になります。login_nodeが未設定の場合、そのURLのホストの部分が空になりシェルを開けないため、login_nodeを設定するか、この項目をfalseにしてください | true |
| show_open_ondemand | ナビゲーションバーに「Open OnDemand」のリンクを表示するかどうか(trueまたはfalse) | true |
| open_ondemand_url | ナビゲーションバーの「Open OnDemand」のリンクと、ナビゲーションバーのロゴのリンクの参照先を上書きします。未設定のままにすると、どちらも要求を受け付けたホスト上のOpen OnDemandのダッシュボードに自動的に解決されるため、サイト毎のURLは不要です。ダッシュボードが別の場所にある場合にのみ設定してください | <このホスト>/pun/sys/dashboard |
| open_ondemand_label | ナビゲーションバーの「Open OnDemand」のリンクのラベル | Open OnDemand |
| navbar_search_placeholder | ナビゲーションバーの検索ボックスのプレースホルダ。このボックスは、ホームページに表示されないアプリケーションとユーザ自身が保存したカスタムテンプレートを含め、すべてのテンプレートを名前、カテゴリ、説明で検索し、そのページの一覧を検索結果に置き換えます | Search apps… |
| show_search | ナビゲーションバーの右側に検索ボックスを表示するかどうか(trueまたはfalse) | true |
| home_directory_label | ナビゲーションバーの「Home Directory」のリンクのラベル | Home Directory |
| home_directory_icon | 「Home Directory」のリンクのアイコンのクラス。Font Awesomeのクラス(例えばfas fa-folder)またはBootstrap Iconsのクラス(例えばbi bi-folder-fill)を指定します。両方のアイコンセットが読み込まれています | fas fa-home |
| shell_access_label | ナビゲーションバーの「Shell Access」のリンクのラベル | Shell Access |
| shell_access_icon | 「Shell Access」のリンクのアイコンのクラス(Font AwesomeまたはBootstrap Icons) | fas fa-terminal |
| open_ondemand_icon | 「Open OnDemand」のリンクのアイコンのクラス(Font AwesomeまたはBootstrap Icons) | bi bi-grid-fill |
| open_ondemand_new_tab | 「Open OnDemand」のリンクとナビゲーションバーのロゴを新しいタブで開きます。同じタブで開く場合はfalseを設定します | true |
| show_navbar_separator | ナビゲーションバーの直下に描画する水平の区切り線。指定できる値は、区切り線なしのfalseまたはnone、透明に向かって薄くなる6pxのグラデーションの線のtrueまたはgradient、1pxの実線のsolidまたはline、3pxの色付きのバーのaccentです。それ以外の値はgradientとして扱われます。「All Templates」のページには枠線付きの一覧があるため、そのページには区切り線は描画されません | false |
| navbar_separator_color | solid/lineとaccentの区切り線の色。gradientは固定の灰色を使用し、この設定を無視します | #C3C8C8 |
+ ナビゲーションバーより下のすべての色とレイアウトを設定します。いくつかの項目は、固定の色ではなく他の項目の値にフォールバックするため、1つを変更すると複数の箇所に影響することがあります。デフォルト値の列に、それが起こる箇所を示しています。 +
+| 項目名 | 設定内容 | デフォルト値 |
|---|---|---|
| home_format | ホームページのアプリケーションの並びのレイアウト。大きなタイル(アイコンと名前)のbig、またはコンパクトな一覧形式のタイルのsmall | big |
| thumbnail_width | ホームページの各アプリケーションのサムネイルの横幅 | 100 |
| accent_color | views/layout.erbにおけるBootstrapの上書きで使用されるアクセントの色。リンク、主要なボタン(Submit、Confirm、Save)、入力欄とスクリプトのエディタのフォーカスの枠、チェックされたチェックボックスとラジオボタン、履歴の並べ替えのリンクのホバー時の状態に使用されます。Bootstrap自身のアクセントの色がデフォルトであるため、未設定のままにするとBootstrapの標準の外観になります | #0D6EFD |
| accent_contrast_color | accent_colorと対になる色。見出しと、accent_colorが適用されるすべての要素のホバー時および選択時の状態に使用されます。白の背景に対して読みやすい色にしてください | #0A58CA |
| body_text_color | ページ本文のデフォルトの文字色 | #212529 |
| highlight_theme | script/submitセクションに使用するhighlight.jsのテーマ名 | vs |
| directive_color | script/submitセクションのスケジューラ指示文の文字色 | #D73A49 |
| navbar_color | ナビゲーションバーの色 | #3D3B40 |
| dropdown_color | ドロップダウンメニューの色 | |
| footer_color | フッタの色 | |
| category_color | ホームページのカテゴリの背景色 | #5522BB |
| description_color | アプリケーションページのアプリケーション説明の背景色 | |
| category_color | ホームページのカテゴリの見出しの背景色 | #5522BB |
| category_text_color | ホームページのカテゴリの見出しの文字色 | |
| description_color | アプリケーションページの上部にある帯の背景色。この帯にはアプリケーションのタイトル、その説明、ヘッダの項目が含まれます。category_colorにフォールバックするため、明示的に設定しない限り、ホームページのカテゴリの見出しの色を変更するとこの帯の色も変わります | category_colorの値(#5522BB) |
| description_text_color | その帯で使用される文字色。ヘッダの項目のラベル(「Script location」「Script name」「Job name」)も含みます。下記の2項目のフォールバック先でもあります | #FFFFFF |
| app_title_color | アプリケーションのタイトル(アプリケーションページの上部に表示されるアプリケーション名)の色。周囲のテーマから継承した見出しの色がdescription_colorに対して読みにくい場合など、タイトルを帯の他の部分と異なる色にする必要があるときに個別に設定します | description_text_colorの値 |
| app_description_text_color | アプリケーションページのタイトルの下に表示されるアプリケーションの説明(アプリケーションのmanifest.ymlのdescriptionから取得)の色 | description_text_colorの値 |
| form_color | アプリケーションページのテキストエリアの背景色 | #BFCFE7 |
| non_script_color | scriptセクションに影響を与えないフォームの背景色 | #FFE28A |
| non_script_button_color | scriptセクションに影響を与えないボタンの背景色 | #FFBF00 |
| submit_color | submitセクションのみに影響を与えるフォームの背景色 | #FFCCCC |
| submit_button_color | submitセクションのみに影響を与えるボタンの背景色 | #FFAAAA |
| history_action_color | 履歴ページの「Cancel Job」と「Delete Info」のボタンの背景色 | #DC3545 |
| favicon | ブラウザのタブのアイコンのファイル名(public/に配置する必要があります)。空にするとfaviconのリンクを出力しません | (None) |
| app_description | 「Selected Templates」のページで、カテゴリの一覧の上に表示される説明文。HTMLを使用できます。description_colorとdescription_text_colorで描画されます。空にすると表示されません | (None) |
| category_badge_colors | カテゴリ名とバッジの背景色の対応。「All Templates」と「New Script」の一覧、およびナビゲーションバーの検索結果で使用されます。指定のないカテゴリは#6C757Dになります。「My Template」のバッジは常に#6F42C1です | (None) |
| all_templates_footer | 「All Templates」の一覧の直下、フッタのバーの上に表示される注記。HTMLを使用できます。「All Templates」のページでのみ、かつshow_footerがtrueの場合にのみ描画されます | (None) |
- apps_dirおよびschedulerは必須です(schedulerはclustersの中に定義しても構いません)。
+ すべてのページの下部にあるバーを設定します。Open ComposerをOpen OnDemandに埋め込む場合はshow_footer: falseを設定し、OOD自身のフッタが使用されるようにしてください。
| 項目名 | 設定内容 | デフォルト値 |
|---|---|---|
| show_footer | フッタのバーを表示するかどうか(trueまたはfalse)。OODに埋め込む場合はfalseを設定し、OOD自身のフッタが使用されるようにします | true |
| footer | フッタのバーに表示する文字またはHTML。デフォルトは改行しない空白であるため、設定していないフッタも高さを保って描画されます。バーを完全に取り除くにはshow_footer: falseを使用してください | |
| footer_color | フッタの背景色。navbar_colorにフォールバックするため、明示的に設定しない限り、ナビゲーションバーの色を変更するとフッタの色も変わります | navbar_colorの値(#3D3B40) |
| footer_text_color | フッタの文字色 | #FFFFFF |
| footer_padding | フッタのバーに適用するBootstrapのパディングのクラス(例えばp-1からp-5) | p-3 |
| footer_ood_logo | 同梱のOpen OnDemandの「Powered by」のロゴをフッタに表示するかどうか(trueまたはfalse)。footer_brand_logoが未設定の場合にのみ参照されます。独自のブランドのロゴは常に表示されます。フッタのロゴを一切表示しないには、footer_ood_logo: falseを設定し、かつfooter_brand_logoを空のままにしてください | true |
| footer_logo_height | フッタのブランドのロゴの高さ。対象はfooter_brand_logo、またはそれが未設定の場合は同梱のOpen OnDemandのロゴです。任意のCSSの長さを指定できます | 24px |
| footer_brand_logo | フッタの左下に表示される「Powered by」のブランドの画像のファイル名(public/に配置する必要があります)。未設定の場合、footer_ood_logoがfalseでなければOpen OnDemandのロゴが使用されます | (None) |
| footer_brand_url | フッタのブランドのロゴをクリックしたときに開くURL | https://openondemand.org/ |
| footer_brand_alt | フッタのブランドのロゴの代替テキスト | Open OnDemandのロゴを使用する場合はPowered by Open OnDemand、それ以外はPowered by |
@@ -104,7 +313,52 @@
+ 各コマンドのパスを設定します。本設定は省略可能です。binとは異なり、上書きした値はファイルの存在を確認せずに記述したとおりに使用されます。そのため、ssh_wrapper経由で到達するリモートホスト上にコマンドがある場合は、こちらを使用してください。
+
+ 必要なコマンドのみを上書きしてください。指定しなかったコマンドはbinにフォールバックし、次にコマンド名のみにフォールバックします。ジョブの投入のコマンドのみを上書きすると、履歴ページとノードページはPUNのPATHが見つけたものを使用することになる点に注意してください。
+
+ ジョブスケジューラがslurmの場合、使用されるコマンドはsbatch(投入)、scontrol(ジョブの詳細)、scancel(キャンセル)、sacct(履歴のテーブル、ジョブの詳細、バッチスクリプト、Job Efficiency)、squeue(履歴のテーブルに追加されるキュー登録中と実行中のジョブ)、sinfo(ノードページ)です。
+
bin_overrides: + sbatch: "/usr/local/bin/sbatch" + scontrol: "/usr/local/bin/scontrol" + scancel: "/usr/local/bin/scancel" + sacct: "/usr/local/bin/sacct" + squeue: "/usr/local/bin/squeue" + sinfo: "/usr/local/bin/sinfo"+ +
+ ジョブスケジューラがpbsproの場合、使用されるコマンドはqsub(投入)、qstat(ジョブの詳細と履歴のテーブル)、qdel(キャンセル)、pbsnodes(ノードページ)です。miyabiのスケジューラはPBS Proのクラスを継承しており、同じコマンド名を使用します。
+
bin_overrides: + qsub: "/usr/local/bin/qsub" + qstat: "/usr/local/bin/qstat" + qdel: "/usr/local/bin/qdel" + pbsnodes: "/usr/local/bin/pbsnodes"+ +
+ ジョブスケジューラがsgeの場合、使用されるコマンドはqsub(投入)、qstat(稼働中のジョブ)、qdel(キャンセル)、qacct(履歴のテーブルの完了したジョブ)、qhost(ノードページ)です。
+
bin_overrides: + qsub: "/usr/local/bin/qsub" + qstat: "/usr/local/bin/qstat" + qdel: "/usr/local/bin/qdel" + qacct: "/usr/local/bin/qacct" + qhost: "/usr/local/bin/qhost"+ +
+ ジョブスケジューラがfujitsu_tcsの場合、使用されるコマンドはpjsub(投入)、pjstat(ジョブの詳細、履歴のテーブル、ノードページ)、pjdel(キャンセル)です。
+
bin_overrides: + pjsub: "/usr/local/bin/pjsub" + pjstat: "/usr/local/bin/pjstat" + pjdel: "/usr/local/bin/pjdel"+ +
ジョブスケジューラのコマンドを実行するときに追加する環境変数を設定します。本設定は省略可能です。
例えばSlurmのconfigless構成でSLURM_CONF_SERVERが必要な場合に利用できます。
@@ -123,8 +377,11 @@
ssh_wrapperを利用してリモートホスト上でジョブスケジューラを実行する場合、scheduler_envはローカルで起動するsshコマンドの環境変数です。
リモート側にも環境変数が必要な場合は、SSHの設定またはwrapperスクリプトで設定してください。
+
+ 適用範囲。scheduler_envは、ジョブの投入だけでなく、Open Composerが実行するすべてのスケジューラのコマンドに適用されます。履歴のテーブル(sacct_all_jobs()、squeue_active_jobs())、ノードページ(sinfo_nodes())、ジョブの詳細のモーダル(sacct_job()、scontrol_job())、Job Efficiencyの区画(efficiency())、バッチスクリプトの取得(batch_script())のすべてに渡されます。そのため、configless構成のSlurmで必要なSLURM_CONF_SERVERのような変数は、これだけですべてのページが動作するようになります。
+
Slurmのジョブ投入時に--export=ALLを使う場合は、trueを設定します。デフォルトはfalseであり、従来通り--export=NONEでジョブを投入します。
この設定はSlurmでのみ使われます。
@@ -140,53 +397,36 @@
これはSlurmのコマンド実行時にPUNの環境変数をコピーします。PUNの環境は通常のログインシェル環境とは異なる場合があるため、注意してください。
- -- 各コマンドのパスを設定します。本設定は省略可能です。 -
- ジョブスケジューラがslurmの場合は、sbatch、scontrol、scancel、sacctを設定できます。
+ --exportのオプションは、アプリケーションが独自の投入オプションを指定していない場合にのみ生成されます。アプリケーションのsubmitセクションが空でないOC_SUBMIT_OPTIONSを設定している場合、その文字列はそのままsbatchに渡され、copy_environmentは完全に無視されます。そのようなアプリケーションで--export=…が必要な場合は、アプリケーション自身で指定してください。
bin_overrides: - sbatch: "/usr/local/bin/sbatch" - scontrol: "/usr/local/bin/scontrol" - scancel: "/usr/local/bin/scancel" - sacct: "/usr/local/bin/sacct"- -
- ジョブスケジューラがpbsproの場合は、qsub、qstat、qdelを設定できます。
-
bin_overrides: - qsub: "/usr/local/bin/qsub" - qstat: "/usr/local/bin/qstat" - qdel: "/usr/local/bin/qdel"- -
- ジョブスケジューラがsgeの場合は、qsub、qstat、qdel、qacctを設定できます。
-
bin_overrides: - qsub: "/usr/local/bin/qsub" - qstat: "/usr/local/bin/qstat" - qdel: "/usr/local/bin/qdel" - qacct: "/usr/local/bin/qacct"+
- ジョブスケジューラがfujitsu_tcsの場合は、pjsub、pjstat、pjdelを設定できます。
+ 履歴ページの必須表示項目は「Job ID」、「Application」、「Script Location」、「Script Name」、「Status」です。
+ それに対して、historyでは追加表示項目を設定します。
+ 本設定を省略した場合、すべての特殊な変数が表示されます。
+ 利用できる特殊な変数は次のとおりです。
bin_overrides: - pjsub: "/usr/local/bin/pjsub" - pjstat: "/usr/local/bin/pjstat" - pjdel: "/usr/local/bin/pjdel"- -
| 特殊な変数 | 表示名 |
|---|---|
OC_HISTORY_JOB_NAME | Job Name |
OC_HISTORY_PARTITION | Partition — ジョブが実行されたキューまたはパーティション |
OC_HISTORY_SUBMISSION_TIME | Submission Time — ジョブが投入された時刻 |
OC_HISTORY_START_TIME | Start Time — ジョブスケジューラが報告するジョブの開始時刻 |
OC_HISTORY_END_TIME | End Time — ジョブスケジューラが報告するジョブの終了時刻 |
OC_HISTORY_OUTPUT_FILE | Output — そのジョブについてジョブスケジューラが記録した標準出力のファイル。ファイル名をクリックすると、その内容がオーバーレイの区画に表示されます。 |
OC_HISTORY_ERROR_FILE | Error — そのジョブについてジョブスケジューラが記録した標準エラーのファイル。ファイル名をクリックすると、その内容がオーバーレイの区画に表示されます。 |
- 履歴ページの必須表示項目は「Job ID」、「Application」、「Script Location」、「Script Name」、「Status」です。それに対して、historyでは追加表示項目を設定します。本設定を省略した場合、「Job Name」、「Partiton」、「Submission Time」が自動的に設定されます。下記のコードと同じです。OC_HISTORY_JOB_NAME、OC_HISTORY_PARTITION、OC_HISTORY_SUBMISSION_TIMEは特殊な変数であり、「Job Name」、「Partiton」、「Submission Time」をそれぞれ指します。
+ ジョブ名、開始時刻、終了時刻を独自のラベルで表示する一般的な設定は次のとおりです。
history: OC_HISTORY_JOB_NAME: - OC_HISTORY_PARTITION: - OC_HISTORY_SUBMISSION_TIME:+ OC_HISTORY_START_TIME: + label: "Start Time" + OC_HISTORY_END_TIME: + label: "End Time"
追加表示項目をなくしたい場合は、空配列を定義します。 @@ -194,7 +434,15 @@
history: []
- ジョブスケジューラから得られるプロファイルの値を表示項目に設定することができます。「Job ID」をクリックすると表示される表の左の値をhistoryに設定します。また、labelを用いると、表示ラベルを設定できます。labelを用いない場合は、そのままの値が用いられます。
+ ジョブスケジューラ自身のアカウンティングの出力から直接取得した項目を追加することもできます。historyのキーが上記のOC_HISTORY_*の変数でない場合、そのキーは、スケジューラのクラスのsacct_all_jobs()メソッドがそのジョブについて返した記録の中から、そのままの名前で参照されます。そのため、値が得られるのは、そのメソッドが実際に要求している項目名のみであり、それ以外の名前は空の列になります。参照はハッシュの完全一致であるため、名前は大文字と小文字を区別し、下記のとおりに記述しなければなりません。「Job ID」をクリックすると開くモーダルに表示される、より長い項目の一覧は別のコマンドによるものであり、それらの名前の多くはここでは使用できません。
+
+ slurmで使用できる名前は、
+ JobID、JobName、Partition、State、Submit、Start、End、Elapsed、WorkDir、Account、TotalCPU、AllocCPUS、ReqMem、ExitCode、NodeList、StdOut、StdErr、SubmitLineです。
+ ローカルのSlurmのビルドが対応していない項目は除外されます。他のスケジューラで使用できる名前は、それぞれのsacct_all_jobs()が構築するキーです。lib/schedulers/を参照してください。
+
+ labelを用いると、列の見出しを設定できます。labelを用いない場合は、項目名がそのまま見出しになります。
history: @@ -206,18 +454,138 @@+ +2.5. history
3. Open OnDemandへの登録
- Open Composerを
/var/www/ood/apps/sys/に保存すると、Open OnDemandのホームページにOpen Composerのアイコンが表示されます。Open Composerのアイコンが表示されない場合は、Open OnDemand用の設定ファイル/var/www/ood/apps/sys/OpenComposer/manifest.ymlを確認してください。 + Open Composerを/var/www/ood/apps/sys/に保存すると、Open OnDemandのホームページにOpen Composerのアイコンが表示されます。表示されない場合は、/var/www/ood/apps/sys/opencomposer/manifest.ymlを確認してください。- Open Composer上のアプリケーションをOpen OnDemandのホームページに表示することもできます。例えば、
/var/www/ood/apps/sys/OpenComposer/sample_apps/Slurmというアプリケーションを表示させたい場合は、同名のディレクトリをOpen OnDemandのアプリケーションディレクトリに作成します(# mkdir /var/www/ood/apps/sys/Slurm)。そして、そのディレクトリ内に下記のようなOpen OnDemand用の設定ファイルmanifest.ymlを作成します。 + Open Composer上のアプリケーションをOpen OnDemandのホームページに表示することもできます。例えば、/var/www/ood/apps/sys/opencomposer/sample_apps/Slurmというアプリケーションを表示させたい場合は、同名のディレクトリをOpen OnDemandのアプリケーションディレクトリに作成します(# mkdir /var/www/ood/apps/sys/Slurm)。そして、そのディレクトリ内に下記のようなOpen OnDemand用の設定ファイルmanifest.ymlを作成します。# /var/www/ood/apps/sys/Slurm/manifest.yml --- name: Slurm -url: https://<your Open OnDemand URL>/pun/sys/OpenComposer/Slurm+url: https://<your Open OnDemand URL>/pun/sys/opencomposer/Slurm
+ デフォルトでは、Open OnDemandでOpen Composerのタイルをクリックすると、アプリケーションが新しいタブで開きます。
+ ood_integration/のファイルを使用すると、Open ComposerがOODのページの中に直接描画される埋め込みモードを有効にできます。OODの本来のナビゲーションバーが上部に残り、その中央にOpen Composerが表示され、下部にOOD自身のフッタが表示されます。ユーザがOODの画面から離れることはありません。
+
+ このページはOOD自身のダッシュボードのレイアウトで描画される1つの文書であるため、ヘッダとフッタはOODの実際のもの(動的なメニュー、ユーザとヘルプのドロップダウン、通知)になり、Content-Security-Policyの変更は必要ありません。 +
+
+ この機能にはOpen OnDemand 3.x以降と、/etc/ood/config/への管理者権限が必要です。
+
+ イニシャライザopencomposer_embed.rbは、OODのダッシュボードの中の/pun/sys/dashboard/ocに小さなリバースプロキシのコントローラを設置し、Open Composerのタイルがそこへ到達するように介入します。プロキシは要求毎に次の処理を行います。
+
/pun/sys/opencomposer/…へ転送します。その際、ユーザのセッションのクッキーを転送するため、そのユーザとして認証された呼び出しになります。/pun/sys/opencomposerを/pun/sys/dashboard/ocに書き換えます。これにより、すべてのリンク、フォームの送信先、アセット、AJAXがプロキシのパス上に留まるため、すべてのページがOODの外枠に包まれた状態が維持されます。<head>のアセットと<body>を、opencomposer_embed.html.erbを介してダッシュボードのレイアウトに組み込み、OODの実際のナビゲーションバーとフッタを与えます。CSSとJavaScriptは接頭辞を書き換えたうえでそのまま流し、画像とフォントは変更せずに通過させ、リダイレクトはLocationをプロキシのパスに書き換えて中継します。$ cd /var/www/ood/apps/sys/ +$ sudo git clone https://github.com/RIKEN-RCCS/OpenComposer.git opencomposer+ +
+ Open Composerは、ユーザが最初にアプリケーションを開いたときに、依存するRubyのgemを自動的にインストールします。 + その初回のアクセスでユーザが待たされることを避けるため、管理者が事前にgemをインストールしておくことができます。 +
+$ cd /var/www/ood/apps/sys/opencomposer +$ sudo cp misc/Gemfile . +$ sudo bundle install+
+ Gemfileが更新されるgit pullを行った後は、bundle installを再度実行してください。
+
$ cd /var/www/ood/apps/sys/opencomposer +$ sudo cp conf.yml.erb.sample conf.yml.erb+
+ OOD統合モードでは、OODがすでに提供しているUIの要素が重複しないように、conf.yml.erbで次のように設定します。
+
show_home_directory: false # OODのFilesメニューがホームディレクトリへのリンクを提供する +show_shell_access: false # OODのClustersメニューがシェルアクセスを提供する +show_open_ondemand: false # OODの中からOODへ戻るリンクは不要 +navbar_logo: ~ # OODのナビゲーションバーがすでにサイトのロゴを表示している +show_footer: false # 埋め込まれた表示の下にOODのフッタが表示される+ +
+ タイルをクリックしたときに新しいウィンドウではなく同じタブで開くように、manifest.ymlにnew_window: falseを追加します。
+
# /var/www/ood/apps/sys/opencomposer/manifest.yml +name: Open Composer +category: Jobs +description: | + Open Composer is an application that creates and submits batch job scripts. +icon: fas://hat-wizard +new_window: false+ +
$ sudo mkdir -p /etc/ood/config/apps/dashboard/initializers +$ sudo mkdir -p /etc/ood/config/apps/dashboard/views/apps + +$ sudo cp /var/www/ood/apps/sys/opencomposer/ood_integration/initializers/opencomposer_embed.rb \ + /etc/ood/config/apps/dashboard/initializers/ + +$ sudo cp /var/www/ood/apps/sys/opencomposer/ood_integration/views/apps/opencomposer_embed.html.erb \ + /etc/ood/config/apps/dashboard/views/apps/+ +
OODのダッシュボードで「Help」→「Restart Web Server」を選択するか、コマンドラインから次を実行します。
+$ sudo httpd -k graceful+
+ これで、Open Composerのタイルをクリックすると、OODのページの中に埋め込まれた状態で開きます。 +
+ +
+ この統合はOODの標準的な仕組み(ダッシュボードのイニシャライザと通常の/punの要求の流れ)のみを使用しており、マルチユーザ環境でも安全です。各要求は要求元のユーザ自身のセッションのクッキーを転送するため、Apacheがそのユーザとして認証し、そのユーザのインスタンスへ振り分けます。他のOpen OnDemandのサイトへも移植できるはずですが、環境に関するいくつかの前提は確認しておく価値があります。上書きの設定はダッシュボードの環境ファイル/etc/ood/config/apps/dashboard/envから読み込まれます。すべての項目にコメントを付けたテンプレートがood_integration/dashboard.env.exampleにあります。
+
| 前提 | サイトが異なる場合 |
|---|---|
Open Composerがsysアプリケーションopencomposerとしてインストールされている(すなわち/pun/sys/opencomposerで配信されている)。 |
+ OC_EMBED_APP_NAMEにインストール先のディレクトリ名(例えばOpenComposer)を設定してください。 |
+
| OODのApache(ポータルのvhost)が、ブラウザが使用したものと同じポートとスキームでループバックから到達できる。443でHTTPSを配信する標準的なホストでは成り立ちます。 | +TLSを終端するロードバランサがOODの前段にあり、ポータルのvhostが実際には別のポートやスキームで待ち受けている場合は、OC_EMBED_UPSTREAM_HOST、OC_EMBED_UPSTREAM_PORT、OC_EMBED_UPSTREAM_SCHEME(http/https)、OC_EMBED_UPSTREAM_IPを適宜設定してください。 |
+
認証がmod_auth_openidcであり、そのセッションのクッキーが/punでダッシュボードに送られる(標準のood-portal.confはそれを/nodeと/rnodeでのみ削除します)。 |
+ 別の認証モジュールを使用している場合、またはクッキーをより広範に削除している場合は、プロキシの上流への呼び出しが認証されるように、ダッシュボードが認証のクッキーを受け取っていることを確認してください。 | +
/etc/ood/config/apps/dashboard/initializers/に独自のRailsのイニシャライザを設置できる。 |
+ 管理された環境や制限の厳しい環境では、これが許可されていない場合や、セキュリティのレビューが必要な場合があります(このイニシャライザはサーバ側でHTTPの呼び出しを行います)。その環境のOODの管理者に確認してください。 | +
+ 性能に関する注意。Open Composerのすべての応答(CSS、JavaScript、画像、フォントを含む)が、ダッシュボードのRubyのプロセスを経由します。通常の対話的な利用では問題ありませんが、高い同時負荷が想定される場合は、ダッシュボードの追加のトラフィックを考慮してください。 +
+ ++ 統合用の2つのファイルを削除し、Apacheを再読み込みします。 +
+$ sudo rm /etc/ood/config/apps/dashboard/initializers/opencomposer_embed.rb +$ sudo rm /etc/ood/config/apps/dashboard/views/apps/opencomposer_embed.html.erb +$ sudo httpd -k graceful+
+ この後は、タイルをクリックすると、Open Composerが同じブラウザのタブで全画面のアプリケーションとして開きます(manifest.ymlのnew_window: falseが残っているためです)。
+ 新しいタブで開く元の動作に戻したい場合は、その行を削除するか元に戻してください。
+
# /var/www/ood/apps/sys/opencomposer/manifest.yml +new_window: true # または行を完全に削除する(trueがOODのデフォルト)+ +
一般ユーザ権限でOpen Composerをインストールすることもできます。ただし、事前に管理者権限でOpen OnDemandのApp Developmentの機能を有効化する必要があります。
@@ -238,11 +606,11 @@
- 「Files」をクリックし、conf.yml.erb.sampleをconf.yml.erbにリネームしください。その後、「Launch Open Composer」をクリックします。
+ 「Launch Open Composer」をクリックします。
- ローカルでOpen Composerを起動させる手順は下記の通りです。
@@ -256,7 +624,7 @@http://localhost:9292にアクセスしてください。なお、ジョブ投入が行えないなどの制限があります。
-
misc/tests/run_tests.rbは、ドキュメントとサンプルアプリケーションの全form.ymlが正しく処理できることを確認するスモークテストです。下記のように実行します。
formセクションがrun.rbと同じ検証を通ることnode --checkを使用。nodeが無い場合はスキップ)node --checkを使用。nodeが無い場合はmacOS同梱のjscを使用し、どちらも無い場合はスキップ)すべてのサンプルが成功すると、終了コード0で下記のように出力されます。失敗した場合は、そのサンプル名と原因が表示され、終了コードは1になります。
---------------------------------------- -42/42 samples passed+44/44 samples passed
これらはスモークテストであり、すべてのサンプルがエラーなく生成できることを保証しますが、ブラウザ上での挙動(ウィジットを操作してDynamic Form Widgetの効果を確認するなど)は対象外です。その部分は実際のブラウザで確認してください。
-
- ジョブスケジューラを追加したい場合、スーパークラスSchedulerが定義されたlib/scheduler.rbを参考にして、lib/schedulers/以下にジョブスケジューラのためのRubyスクリプトを作成してください。下記のPBS Pro(lib/schedulers/pbspro.rb)のようにSchedulerクラスを継承してください。ジョブを投入するsubmit()メソッド、ジョブをキャンセルするcancel()メソッド、ジョブの情報を問い合わせるquery()メソッドを定義する必要があります。
+ ジョブスケジューラを追加したい場合、lib/scheduler.rbで定義されているSchedulerクラスを継承するRubyスクリプトをlib/schedulers/以下に作成してください。lib/schedulers/pbspro.rbのPBS Proが下記のようにしているのと同様です。
class Pbspro < Scheduler
- また、いくつかのクラスタでは、ジョブスケジューラのコマンド(例:qstat)がラッパースクリプトになっていて、オリジナルのコマンドをユーザが実行できない場合があります。そのような場合、既存のスケジューラのスクリプトを少し変更することで対応できることがあります。例えば、lib/schedulers/miyabi.rbでは、下記のようにPBS Proのスケジューラを継承して新しいクラスMiyabiを定義しています。Miyabiクラスではquery()メソッドだけが定義されており、他のメソッドはlib/schedulers/pbspro.rbで定義されたものを利用しています。
+ Schedulerはsubmit()、cancel()、query()を抽象メソッドとして宣言し、それ以外のすべてのフックには、動作はするが何もしないデフォルトの実装を用意しています。それらのデフォルトは失敗しないため、投入とキャンセルのみを実装したクラスでも、ジョブの投入とキャンセルは動作しますが、履歴ページとノードページは何も表示されないままになります。フックは次のとおりです。
+
| メソッド | 対応する機能 | 上書きしない場合 |
|---|---|---|
submit() | アプリケーションページからのジョブの投入 | 実装が必須 |
cancel() | 履歴ページの「Cancel Job」 | 実装が必須 |
query() | スーパークラスのインタフェースの一部。履歴ページのジョブの状態はsacct_all_jobs()から取得されます | 呼び出される場合は実装が必須 |
sacct_all_jobs() | 履歴ページ全体。どのジョブが存在するか、およびその状態、時刻、作業ディレクトリ、標準出力と標準エラーのパスの唯一の情報源です | 何も返さないため、履歴ページは常に「(No Jobs)」と表示します |
state_to_oc_status() | ジョブスケジューラの生の状態の文字列を、Queued/Running/Completed/Cancelled/Failedのバッジに対応付けます | すべてのジョブの状態が不明として報告されます |
valid_job_id?() | ジョブスケジューラから得たジョブIDのうち、どれを履歴のテーブルに受け入れるかを決定します | すべて数字のIDのみが受け入れられるため、配列ジョブなどの複合的なIDは除外されます |
sinfo_nodes() | ノードページ。ノード毎に1つの配列を返します。名前、状態、CPU(割り当て済み/空き/その他/総数)、メモリ、空きメモリ、汎用リソース、使用中の汎用リソースです | ノードページには行が表示されません |
sacct_job()とscontrol_job() | ジョブIDをクリックすると開くジョブの詳細のモーダル。それぞれアカウンティングの記録と現在の記録です | 任意。モーダルは詳細が利用できないことを表示します |
batch_script() | 投入したスクリプトをジョブスケジューラから取得します。ジョブスクリプトの表示で使用され、history_store_scriptがfalseの場合は必須です | 任意。履歴のデータベースにスクリプトが無いジョブでは、スクリプトが表示されません |
squeue_active_jobs() | アカウンティングのコマンドがまだ報告していないキュー登録中と実行中のジョブを、sacct_all_jobs()に補います。sacct_all_jobs()と同じキー名を返さなければなりません | 任意。投入した直後のジョブは、アカウンティングが追いつくまで履歴ページに表示されない場合があります |
squeue_start_times() | 待機中のジョブの開始時刻の見積り。完全性のためSchedulerで宣言されていますが、query()と同様に、現在これを呼び出す処理はありません | 任意。現時点でこれに依存する機能はありません |
efficiency() | history_efficiencyがtrueの場合のJob Efficiencyの区画 | 任意。この区画は、このスケジューラでは効率の情報に対応していないことを表示します |
+ すべてのフックは、末尾の引数としてbin、bin_overrides、ssh_wrapper、scheduler_envを受け取ります。scheduler_env(2.3. scheduler_envを参照)が有効になるように、各コマンドはOpen3.capture3を直接呼び出すのではなく、継承したcapture_scheduler_command(scheduler_env, command)のヘルパを通して実行してください。
+
+ また、いくつかのクラスタでは、ジョブスケジューラのコマンド(例:qstat)がラッパースクリプトになっていて、オリジナルのコマンドをユーザが実行できない場合があります。そのような場合、既存のスケジューラのスクリプトを少し変更することで対応できることがあります。例えば、lib/schedulers/miyabi.rbでは、PBS Proのスケジューラを継承したMiyabiクラスを定義し、query()とsacct_all_jobs()の2つのメソッドのみを上書きしています。これは、Miyabiでは完了したジョブに対してサイト固有のqstat -H --hdayの形式が必要なためです。それ以外のメソッドはすべてlib/schedulers/pbspro.rbのものを利用しています。
class Miyabi < Pbspro
ジョブスケジューラのスクリプトの作成後、./conf.yml.erbで下記のようにスケジューラを指定します。
scheduler: miyabi+ diff --git a/docs/manual.html b/docs/manual.html index 2a9af308..e265c6ef 100644 --- a/docs/manual.html +++ b/docs/manual.html @@ -15,8 +15,18 @@
Open Composer is a web application to submit batch jobs to an HPC cluster system from a web browser. - Open Composer consists of "Home page", "Application page", and "History page". + It consists of the home page ("Selected Templates"), the "All Templates" page, the "Load or Create a Script from Disk" file browser, an application page for each template, the "History" page, and the "Nodes" page.
Displays application icons by category.
- On the left side of the navigation bar are links to the "Home page", "Application page", and "History page".
- On the right side of the navigation bar are links to the Open OnDemand "Home Directory", "Shell Access", and "Dashboard".
- Note that "Shell Access" is only displayed if login_node is set in conf.yml.erb.
+ The home page layout can be configured by the administrator via the home_format setting in conf.yml.erb.
+ The big format (default) shows large tiles with the application icon and name; the small format shows compact list-style entries.
+ + The navigation bar contains the following links: +
+navbar_logo, your site's logo appears in the top-left corner, before these links, and is itself a link back to Open OnDemand. It can be hidden without unsetting it via show_navbar_logo: false, and is normally left off when Open Composer runs inside Open OnDemand, whose own navigation bar already shows the site logo.
+ My Template. Click an entry to open it.show_search: false in conf.yml.erb.show_home_directory: false in conf.yml.erb.show_shell_access: false, and also hidden if your administrator has not configured a login node for the cluster in use — without one there is nothing for the link to connect to. The label and icon are set via shell_access_label and shell_access_icon, so your site may have renamed it.show_open_ondemand: false. The label is set via open_ondemand_label; the URL defaults to the dashboard on the same host and only needs open_ondemand_url if your dashboard lives elsewhere.
- + The "My Custom Templates" section appears below the application categories. + It shows your saved templates as thumbnails, using the same icon as the application the template was created from. +
+
+ Templates are stored per-user under data_dir/templates/.
+ If no templates have been saved yet, the section displays a short hint explaining how to create one.
+
+ Once you have saved at least one template, a "Search templates…" box appears in the section header. + It filters the tiles by template name and description as you type, and reports "No templates match your search." when nothing matches. + It only affects this section; the search box in the navigation bar covers everything. +
++ You can also reorder the tiles by dragging one and dropping it where you want it. + The new order is saved automatically and is used every time the section is shown. + A few points are worth knowing: +
++ The All Templates link in the navigation bar shows every template as one full-height scrolling list instead of icon tiles. + Because the list is not filtered, this is the place to look for something you cannot find on the home page: + it also includes applications that your site has marked as hidden, which never appear in the home page categories. +
+
+ + The list is in three groups, in this order: +
++ Each row shows the template name with its description underneath, preceded by badges: +
+GPU badge on applications that are GPU applications.My Template badge on your own saved templates.+ Click a row to open that application's page. Clicking one of your own templates opens its application page with your saved values already filled in. + Typing in the navigation bar's search box replaces this list with the matching entries. + Your site may show a short note along the bottom of the page. +
+ +
+ If you already have a job script on the cluster, you can open it in Open Composer instead of rebuilding it in a form.
+ The "Load or Create a Script from Disk" button is at the top of the home page, above the application categories,
+ and again at the top of the "New Custom Template — Choose a Style" page.
+ Its label can be changed by your administrator (load_script_label), and the button is absent if show_load_script: false is set.
+
+ + The button opens a full-page file browser, starting in your home directory. Its controls are: +
++ The directory you are in is kept in the page's address, so the browser's Back and Forward buttons walk through the directories you have visited, and reloading keeps you where you were. +
+.sl, .sh, .sbatch, .batch, .slurm or .bash can be opened.+ The green New Script button starts a new script instead of opening an existing one. + It opens a list of every application — hidden ones included, with the featured templates at the top — and the directory you were browsing is carried across, + so the application page you choose opens with its "Script location" already set to that directory. +
+ +Generates a job script. When you enter values in the web form on the left side of the page, @@ -45,86 +180,202 @@
+
clusters: in conf.yml.erb — those clusters may all run the same scheduler. The job script will be submitted to the selected cluster.
-
-
+ Applications provided by your site can be more elaborate than the generic form above. + The example below shows a quantum chemistry application whose form pulls the available software versions from the cluster's module system, + so the dropdowns only ever offer versions that are actually installed: +
+
+
+ + Clicking Submit writes the script to disk and submits it to the cluster. You stay on the application page, where a green banner confirms the Job ID and offers a History page link; follow that link to see the new job at the top of the History table. + Two things can happen first, depending on how your site has configured Open Composer: +
+module lines, a dialog asks you to confirm before submitting.
+ This usually means that a form field meant to add a command to the script is still empty. You can submit anyway, but the job will run and do nothing.
-
-
~/.ssh directory and authorize it, so the job can be submitted without a password prompt.
+ The public key is appended to ~/.ssh/authorized_keys, and because the key does not use a default id_* name an IdentityFile line under Host * is added to your ~/.ssh/config so ssh offers it. This happens once and is silent; an SSH key you already have is never replaced.
+ The "Save as Custom Template" button appears at the bottom of the script panel on every application page, directly below the Submit button. + Clicking it opens a dialog where you can give the template a name and an optional description. + The current form values, together with the application's icon and path, are saved as a reusable template. +
++ When you open an application page from the + New Custom Template picker — or from "Load or Create a Script from Disk" and "New Script" started from that picker — + the page opens in template mode. The page is then for building a template, not for running a job, so: +
++ To run the job, save the template first. Saving returns you to the home page, where your new template appears in "My Custom Templates". + Open it from there (or from the All Templates page) and the same form reopens with your values and with the Submit button available. + If you did not want a template at all, reach the application from the home page categories or from the All Templates page instead of the picker; + those routes open the ordinary application page with Submit in place. +
+ ++ You can browse the job history. You can also check the status of jobs and cancel running jobs. + The page consists of four sections: Filter, Jobs, Actions and Display. +
+ +
+
+ + The table lists every job the scheduler reports for your user account — not only the jobs you submitted through Open Composer. + Open Composer stores its own record of the jobs it submitted (application, script location, script name, and the script itself) and joins that onto the scheduler's data. + Rows for jobs submitted some other way, for example from a terminal, therefore look different: +
+- You can browse the job history. You can also check the status of jobs and cancel running jobs. - The page consists of four sections: - Filter, - Jobs, - Actions, and - Display. + By default the page asks the scheduler for a seven-day window: today and the six days before it. + Jobs older than that are not listed until you widen the range. While the range is (ALL) no date filter is applied at all, so every queued and running job is listed whatever its date; once you pick a Range, that filter applies to queued and running jobs too, so a long-pending job submitted before the window drops out of the table.
- -
-
+ + The Range menu under the "Detail" button changes the window: +
+
-
-
+ The Nodes page shows the current status of the cluster's compute nodes. + It is accessible via the "Nodes" link in the navigation bar. + The data is read once, when the page loads; the page does not refresh itself. +
+
+ gpu or nvme.
+ Each GRES column is broken down by subtype (e.g. A100, H100) and
+ shows available vs. total counts.
+ These columns follow "Memory", in alphabetical order.gpu shows only GPU nodes.- Open ComposerはWebブラウザからHPCクラスタにバッチジョブを投入することができるWebアプリケーションです。Open Composerは「ホームページ」、「アプリケーションページ」、「履歴ページ」の3つのページから構成されています。 + Open ComposerはWebブラウザからHPCクラスタシステムにバッチジョブを投入することができるWebアプリケーションです。 + ホームページ(「Selected Templates」)、「All Templates」ページ、「Load or Create a Script from Disk」のファイルブラウザ、テンプレート毎のアプリケーションページ、「History」ページ、「Nodes」ページから構成されています。
- アプリケーションのアイコンがカテゴリ毎に表示されます。ナビゲーションバーの左側には、それぞれ「ホームページ」、「アプリケーションページ」、「履歴ページ」へのリンクがあります。ナビゲーションバーの右側には、それぞれOpen OnDemandの「Home Directory」、「Shell Access」、「ダッシュボード」へのリンクがあります。ただし、「Shell Access」はconf.yml.erbでlogin_nodeが設定されている場合のみ表示されます。
+ アプリケーションのアイコンがカテゴリ毎に表示されます。
+ ホームページのレイアウトは、管理者がconf.yml.erbのhome_formatで設定できます。
+ big(デフォルト)はアプリケーションのアイコンと名前を大きなタイルで表示し、smallはコンパクトな一覧形式で表示します。
+ + ナビゲーションバーには以下のリンクがあります。 +
+navbar_logoを設定している場合、これらのリンクの手前(左上隅)にサイトのロゴが表示され、ロゴ自体がOpen OnDemandへ戻るリンクになります。show_navbar_logo: falseにすると、navbar_logoの値を消さずにロゴだけを非表示にできます。Open OnDemandに埋め込んで動作させる場合は、Open OnDemand側のナビゲーションバーがすでにサイトのロゴを表示しているため、通常はロゴを表示しません。
+ My Templateのタグが付きます。項目をクリックすると開きます。conf.yml.erbでshow_search: falseを設定している場合、このボックスは表示されません。conf.yml.erbでshow_home_directory: falseが設定されている場合は非表示です。show_shell_access: falseが設定されている場合は非表示です。また、対象のクラスタに管理者がログインノードを設定していない場合も、接続先が存在しないため非表示になります。ラベルとアイコンはshell_access_labelとshell_access_iconで設定されるため、サイトによって名称が変更されている場合があります。show_open_ondemand: falseが設定されている場合は非表示です。ラベルはopen_ondemand_labelで設定します。URLは同じホスト上のダッシュボードが既定値であり、ダッシュボードが別の場所にある場合にのみopen_ondemand_urlを設定します。
- + 「My Custom Templates」の区画は、アプリケーションのカテゴリの下に表示されます。 + 保存したテンプレートが、作成元のアプリケーションと同じアイコンのサムネイルで表示されます。 +
+
+ テンプレートはユーザ毎にdata_dir/templates/以下に保存されます。
+ テンプレートがまだ1つも保存されていない場合は、作成方法を説明する短い案内が表示されます。
+
+ テンプレートを1つ以上保存すると、区画のヘッダに「Search templates…」ボックスが表示されます。 + 入力に応じてテンプレートの名前と説明でタイルを絞り込み、一致するものがない場合は「No templates match your search.」と表示します。 + このボックスはこの区画のみに作用します。ナビゲーションバーの検索ボックスは全体を対象とします。 +
++ タイルはドラッグして任意の位置にドロップすることで並べ替えることもできます。 + 新しい並び順は自動的に保存され、以降この区画を表示する際に常に使用されます。 + 以下の点に注意してください。 +
++ ナビゲーションバーの「All Templates」をクリックすると、すべてのテンプレートが、アイコンのタイルではなく、ページの高さいっぱいの1つのスクロールする一覧として表示されます。 + この一覧は絞り込まれていないため、ホームページで見つけられないものを探す場所になります。 + ホームページのカテゴリには決して表示されない、サイトが非表示に設定したアプリケーションも含まれます。 +
+
+ + 一覧は次の順序で3つのグループに分かれています。 +
++ 各行にはテンプレートの名前とその下に説明が表示され、その手前にバッジが付きます。 +
+GPUのバッジが付きます。My Templateのバッジが付きます。+ 行をクリックすると、そのアプリケーションのページが開きます。自分のテンプレートをクリックすると、保存した値が入力された状態でアプリケーションページが開きます。 + ナビゲーションバーの検索ボックスに入力すると、この一覧は一致した項目に置き換わります。 + ページの下部に、サイト独自の短い注記が表示される場合があります。 +
+ +
+ すでにクラスタ上にジョブスクリプトがある場合は、フォームで作り直すのではなく、そのままOpen Composerで開くことができます。
+ 「Load or Create a Script from Disk」ボタンは、ホームページのアプリケーションのカテゴリの上にあり、「New Custom Template — Choose a Style」ページの上部にもあります。
+ ラベルは管理者が変更できます(load_script_label)。show_load_script: falseが設定されている場合、このボタンは表示されません。
+
+ + このボタンは、ホームディレクトリから始まる全画面のファイルブラウザを開きます。操作部は次のとおりです。 +
++ 現在のディレクトリはページのアドレスに保持されるため、ブラウザの「戻る」と「進む」で訪問したディレクトリを辿ることができ、再読み込みしても同じ場所に留まります。 +
+.sl、.sh、.sbatch、.batch、.slurm、.bashで終わるファイルを開くことができます。+ 緑色の「New Script」ボタンは、既存のスクリプトを開くのではなく、新しいスクリプトの作成を開始します。 + 非表示のものも含むすべてのアプリケーションの一覧(特集されているテンプレートが先頭)が開き、閲覧していたディレクトリが引き継がれます。 + そのため、選択したアプリケーションページは「Script location」がそのディレクトリに設定された状態で開きます。 +
+ +ジョブスクリプトを生成します。ページ左のWebフォームに値を入力すると、ページ右のテキストエリアにジョブスクリプトが動的に生成されます。テキストエリアは自由に編集できます。テキストエリアの下の「Submit」ボタンをクリックすると、生成されたジョブスクリプトがHPCクラスタに投入されます。
-
+
conf.yml.erbのclusters:に複数のクラスタを定義している場合のみ表示されます。それらのクラスタが同じジョブスケジューラを使用していても構いません。選択されたクラスタにジョブスクリプトが投入されます。
-
-
-
-
+ サイトが提供するアプリケーションは、上記の汎用のフォームより高度な場合があります。 + 次の例は量子化学のアプリケーションで、フォームがクラスタのモジュールシステムから利用可能なソフトウェアのバージョンを取得するため、ドロップダウンには実際にインストールされているバージョンのみが表示されます。 +
+
+
+ + 「Submit」をクリックすると、スクリプトをディスクに書き出し、クラスタに投入します。ページはアプリケーションページに留まり、緑色のバナーがJob IDを示して「History page」へのリンクを提供します。そのリンクを辿ると、履歴のテーブルの先頭に新しいジョブが表示されます。 + サイトの設定によっては、その前に次の2つのことが起こる場合があります。 +
+moduleの行のみで構成されている場合、投入する前に確認のダイアログが表示されます。
+ これは通常、スクリプトにコマンドを追加するためのフォームの項目が空のままであることを意味します。そのまま投入することもできますが、ジョブは実行されても何もしません。
+ ~/.sshディレクトリにパスフレーズなしのSSH鍵を生成して認証に使用できるよう登録することがあります。これにより、パスワードの入力を求められずにジョブを投入できます。
+ 公開鍵は~/.ssh/authorized_keysに追記されます。また、鍵の名前が既定のid_*ではないため、sshがその鍵を提示するように、~/.ssh/configのHost *にIdentityFileの行が追加されます。これは1度だけ行われ、通知は表示されません。すでに存在するSSH鍵が置き換えられることはありません。
+ 「Save as Custom Template」ボタンは、すべてのアプリケーションページで、スクリプトの区画の下部、「Submit」ボタンの直下に表示されます。 + クリックすると、テンプレートの名前と、任意で説明を入力するダイアログが開きます。 + 現在のフォームの値が、アプリケーションのアイコンとパスとともに、再利用可能なテンプレートとして保存されます。 +
++ 「+ New Custom Template」の選択ページから、あるいはその選択ページから開始した「Load or Create a Script from Disk」や「New Script」からアプリケーションページを開いた場合、そのページはテンプレートモードで開きます。 + このときページは、ジョブを実行するためではなく、テンプレートを作成するためのものになるため、次のようになります。 +
+- これまでのジョブ履歴を閲覧できます。また、ジョブの実行状況の確認や実行中のジョブの停止が可能です。Filter、Jobs、Actions、Displayの4つの区画があります。 + ジョブを実行するには、まずテンプレートを保存してください。保存するとホームページに戻り、「My Custom Templates」に新しいテンプレートが表示されます。 + そこから(または「All Templates」ページから)開くと、同じフォームが入力した値とともに再度開き、「Submit」ボタンが利用できます。 + テンプレートを作成する意図がなかった場合は、選択ページからではなく、ホームページのカテゴリまたは「All Templates」ページからアプリケーションを開いてください。 + これらの経路では、「Submit」がある通常のアプリケーションページが開きます。
-
+ + これまでのジョブ履歴を閲覧できます。また、ジョブの実行状況の確認や実行中のジョブの停止が可能です。 + ページはFilter、Jobs、Actions、Displayの4つの区画から構成されます。 +
+ +
+
+ + テーブルには、Open Composerから投入したジョブだけでなく、ジョブスケジューラが自分のユーザアカウントについて報告するすべてのジョブが表示されます。 + Open Composerは、自身が投入したジョブについて独自の記録(アプリケーション、スクリプトの保存先、スクリプトのファイル名、およびスクリプトそのもの)を保持しており、それをジョブスケジューラのデータに結合します。 + そのため、例えばターミナルなど別の方法で投入したジョブの行は、次のように異なって見えます。 +
++ 既定では、ページはジョブスケジューラに7日間(当日とその前の6日間)の範囲を問い合わせます。 + それより古いジョブは、範囲を広げるまで表示されません。 + 範囲が(ALL)の間は日付による絞り込みが一切行われないため、キューに登録されているジョブと実行中のジョブは、日付に関係なくすべて表示されます。Rangeを選択すると、その絞り込みはキューに登録されているジョブと実行中のジョブにも適用されるため、その範囲より前に投入され、長くキューに残っているジョブはテーブルから外れます。 +
++ 「Detail」ボタンの下のRangeのメニューで、この範囲を変更できます。 +
+
-
-
+ ノードページは、クラスタの計算ノードの現在の状態を表示します。 + ナビゲーションバーの「Nodes」のリンクからアクセスできます。 + データはページの読み込み時に1度だけ取得され、ページが自動で更新されることはありません。 +
+
+ gpuやnvme)。
+ 各GRESの列はサブタイプ(例えばA100、H100)毎に分けられ、利用可能数と総数を表示します。
+ これらの列は「Memory」の後に、アルファベット順で並びます。gpuと入力するとGPUノードのみが表示されます。