cli_filter Plugin API

Overview

This document describes Slurm cli_filter plugins and the API that defines them.
このドキュメントでは、Slurmcli_filterプラグインとそれらを定義するAPIについて説明します。
It is intended as a resource to programmers wishing to write their own Slurm cli_filter plugins.
これは、独自のSlurmcli_filterプラグインを作成したいプログラマー向けのリソースとして意図されています。

The purpose of the cli_filter plugins is to provide programmatic hooks during the execution of the salloc, sbatch, and srun command line interface (CLI) programs.
cli_filterプラグインの目的は、salloc、sbatch、およびsrunコマンドラインインターフェイス（CLI）プログラムの実行中にプログラムフックを提供することです。
Three hooks are defined:
3つのフックが定義されています。

setup_defaults — Called before any option processing is done, per job-pack, allowing a plugin to replace default option values.
setup_defaults —ジョブパックごとにオプション処理が実行される前に呼び出され、プラグインがデフォルトのオプション値を置き換えることができるようにします。
pre_submit — Called after option processing per job-pack but before any communication is made with the slurm controller.
pre_submit —ジョブパックごとのオプション処理の後、slurmコントローラーとの通信が行われる前に呼び出されます。
This location is ideal for policy enforcement because the plugin can read all the options supplied by the user (as well as the environment) - thus invalid job requests can be stopped before they ever reach the slurmctld.
プラグインはユーザー（および環境）によって提供されたすべてのオプションを読み取ることができるため、この場所はポリシーの実施に理想的です。したがって、無効なジョブ要求は、slurmctldに到達する前に停止できます。
post_submit — Called after the jobid (and, in the case of srun, after the stepid) is generated, and typically before or in parallel with job execution.
post_submit —ジョブIDが生成された後（およびsrunの場合はステップIDの後）、通常はジョブの実行前または実行と並行して呼び出されます。
In combination with data collected in the pre_submit() hook, this is an ideal location for logging activity.
pre_submit（）フックで収集されたデータと組み合わせると、これはアクティビティをログに記録するための理想的な場所です。

cli_filter plugins vary from the job_submit plugin as it is entirely executed client-side, whereas job_submit is processed server-side (within the slurm controller).
cli_filterプラグインは、job_submitプラグインとは異なり、完全にクライアント側で実行されますが、job_submitはサーバー側（slurmコントローラー内）で処理されます。
The benefit of the cli_filter is that it has access to all command line options in a simple and consistent interface as well as being safer to run disruptive operations (e.g., quota checks or other long running operations you might want to use for integrating policy decisions), which can be problematic if run from the controller.
cli_filterの利点は、シンプルで一貫性のあるインターフェイスですべてのコマンドラインオプションにアクセスできるだけでなく、中断を伴う操作（たとえば、クォータチェックやポリシー決定の統合に使用する可能性のあるその他の長時間実行操作）をより安全に実行できることです。、これはコントローラーから実行すると問題になる可能性があります。
The disadvantage of the cli_filter is that it must not be relied upon for security purposes as an enterprising user can circumvent it simply by providing loading an alternate slurm.conf with the CliFilterPlugins option disabled.
cli_filterの欠点は、CliFilterPluginsオプションを無効にして代替slurm.confをロードするだけで、進取の気性のあるユーザーが回避できるため、セキュリティ目的で信頼してはならないことです。
If you plan to use the cli_filter for managing policies, you should also configure a job_submit plugin to reinforce those policies.
ポリシーの管理にcli_filterを使用する場合は、それらのポリシーを強化するようにjob_submitプラグインも構成する必要があります。

Slurm cli_filter plugins must conform to the Slurm Plugin API with the following specifications:
Slurm cli_filterプラグインは、次の仕様のSlurmプラグインAPIに準拠している必要があります。

const char plugin_name[]="full text name"

A free-formatted ASCII text string that identifies the plugin.
プラグインを識別する自由形式のASCIIテキスト文字列。

const char plugin_type[]="major/minor"

The major type must be "cli_filter." The minor type can be any suitable name for the type of job submission package.
メジャータイプは「cli_filter」である必要があります。マイナータイプは、ジョブ送信パッケージのタイプに適した名前にすることができます。
We include samples in the Slurm distribution for
のSlurmディストリビューションにサンプルを含めます

none — An empty plugin with no actions taken, a useful starting template for a new plugin.
none —アクションが実行されていない空のプラグイン。新しいプラグインの便利な開始テンプレートです。

const uint32_t plugin_version
If specified, identifies the version of Slurm used to build this plugin and any attempt to load the plugin from a different version of Slurm will result in an error.
指定されている場合、このプラグインのビルドに使用されたSlurmのバージョンを識別し、異なるバージョンのSlurmからプラグインをロードしようとするとエラーが発生します。
If not specified, then the plugin may be loaded by Slurm commands and daemons from any version, however this may result in difficult to diagnose failures due to changes in the arguments to plugin functions or changes in other Slurm functions used by the plugin.
指定しない場合、プラグインは任意のバージョンのSlurmコマンドおよびデーモンによってロードされる可能性がありますが、プラグイン関数の引数の変更またはプラグインが使用する他のSlurm関数の変更により、障害の診断が困難になる可能性があります。

Slurm can be configured to use multiple cli_filter plugins if desired, however the lua plugin will only execute one lua script named "cli_filter.lua" located in the default script directory (typically the subdirectory "etc" of the installation directory).
Slurmは、必要に応じて複数のcli_filterプラグインを使用するように構成できますが、luaプラグインは、デフォルトのスクリプトディレクトリ（通常はインストールディレクトリのサブディレクトリ "etc"）にある "cli_filter.lua"という名前のluaスクリプトを1つだけ実行します。

API Functions

All of the following functions are required.
以下のすべての機能が必要です。
Functions which are not implemented must be stubbed.
実装されていない関数はスタブする必要があります。

int init(void)

Description:
Called when the plugin is loaded, before any other functions are called. Put global initialization here.
プラグインがロードされたときに、他の関数が呼び出される前に呼び出されます。ここにグローバル初期化を配置します。

Returns:
SLURM_SUCCESS on success, or
SLURM_ERROR on failure.

void fini(void)

Description:
Called when the plugin is removed.
プラグインが削除されたときに呼び出されます。
Clear any allocated storage here.
ここで割り当てられたストレージをすべてクリアします。

Returns: None.

Note: These init and fini functions are not the same as those described in the dlopen (3) system library.
注：これらのinitおよびfini関数は、dlopen（3）システムライブラリで説明されているものと同じではありません。
The C run-time system co-opts those symbols for its own initialization.
Cランタイムシステムは、独自の初期化のためにこれらのシンボルを採用します。
The system _init() is called before the Slurm init(), and the Slurm fini() is called before the system's _fini().
システム_init（）はSlurm init（）の前に呼び出され、Slurm fini（）はシステムの_fini（）の前に呼び出されます。

int setup_defaults(slurm_opt_t *options, bool early)

Description:
This function is called by the salloc, sbatch, or srun command line interface (CLI) programs shortly before processing any options from the environment, command line, or script (#SBATCH).
この関数は、環境、コマンドライン、またはスクリプト（#SBATCH）からのオプションを処理する直前に、salloc、sbatch、またはsrunコマンドラインインターフェイス（CLI）プログラムによって呼び出されます。
The hook may be run multiple times per job-pack, once for an early pass (if implemented by the CLI), and again for the main pass.
フックは、ジョブパックごとに複数回実行できます。1回はアーリーパス（CLIで実装されている場合）、もう1回はメインパスです。
The options and early arguments are meant to be passed to slurm_option_set() which will set the option if it is in the appropriate pass.
オプションと初期引数はslurm_option_set（）に渡されることを意図しており、適切なパスにある場合はオプションを設定します。
Failures to set an option may be a symptom of trying to set the option on the wrong pass.
オプションの設定に失敗すると、間違ったパスでオプションを設定しようとしたことの症状である可能性があります。
Given that you should not return SLURM_ERROR simply because of a failure to set an option.
オプションの設定に失敗したという理由だけでSLURM_ERRORを返すべきではないことを考えると。

Arguments:
options (input) slurm option data structure; meant to be passed to the slurm_option_* API within src/common/slurm_opt.h.
options（入力）slurmオプションのデータ構造。src / common /slurm_opt.h内のslurm_option_ * APIに渡されることを意味します。

early (input) boolean indicating if this is the early pass or not; meant to be passed to the slurm_option_* API within src/common/slurm_opt.h.
これがアーリーパスであるかどうかを示すアーリー（入力）ブール値。src / common /slurm_opt.h内のslurm_option_ * APIに渡されることを意味します。

Returns:
SLURM_SUCCESS on success, or
成功した場合はSLURM_SUCCESS、または

SLURM_ERROR on failure, will terminate execution of the CLI.
SLURM_ERRORが失敗すると、CLIの実行が終了します。

int pre_submit(slurm_opt_t *options, int pack_offset)

Description:
This function is called by the CLI after option processing but before any communication with the slurmctld is made.
この関数は、オプションの処理後、slurmctldとの通信が行われる前にCLIによって呼び出されます。
This is after all setup_defaults() hooks are executed (for the current job-pack), environment variables processed, command line options and #SBATCH directives interpreted.
これは、すべてのsetup_defaults（）フックが（現在のジョブパックに対して）実行され、環境変数が処理され、コマンドラインオプションと#SBATCHディレクティブが解釈された後です。
pre_submit() is called before any parts of the data structure are rewritten, so it is safe to both read and write or unset any options from the plugin that you desire.
pre_submit（）は、データ構造の一部が書き換えられる前に呼び出されるため、必要なプラグインのオプションの読み取りと書き込みの両方を行ったり、設定を解除したりしても安全です。
Note that post_submit() cannot safely read (or write) the options, so you should save any state for logging in post_submit() during pre_submit().
post_submit（）はオプションを安全に読み取る（または書き込む）ことができないため、pre_submit（）中にpost_submit（）にログインするための状態を保存する必要があることに注意してください。
This function is called once per job pack.
この関数は、ジョブパックごとに1回呼び出されます。

Arguments:
options (input/output) the job allocation request specifications.
オプション（入力/出力）ジョブ割り当て要求の仕様。

pack_offset (input) integer value for the current pack offset; should be used as a key when storing data for communication between pre_submit() and post_submit().
pack_offset（入力）現在のパックオフセットの整数値。pre_submit（）とpost_submit（）間の通信用のデータを保存する際のキーとして使用する必要があります。

void post_submit(int pack_offset, uint32_t jobid, uint32_t stepid)

Description:
This function is called by the CLI after a jobid (and, if srun, a stepid) has been assigned by the controller.
この関数は、コントローラーによってジョブID（および、srunの場合はステップID）が割り当てられた後にCLIによって呼び出されます。
It is no longer safe to read or write to the options data structure, so it has been removed from this function.
オプションデータ構造の読み取りまたは書き込みは安全ではなくなったため、この関数から削除されました。
You should save any state you need in pre_submit() using pack_offset as a key and access it here.
pack_offsetをキーとして使用してpre_submit（）に必要な状態を保存し、ここからアクセスする必要があります。
This function is called once per job-pack.
この関数は、ジョブパックごとに1回呼び出されます。

Arguments:
options pack_offset (input) integer value for the current pack offset; should be used as a key when storing data for communication between pre_submit() and post_submit().
pack_offset（入力）現在のパックオフセットの整数値。pre_submit（）とpost_submit（）間の通信用のデータを保存する際のキーとして使用する必要があります。

jobid (input) job id of the job
ジョブID（入力）ジョブのジョブID

stepid (input) step id of the job if appropriate, NO_VAL otherwise
stepid（入力）必要に応じてジョブのステップID、それ以外の場合はNO_VAL

Last modified 29 April 2019