Slurm REST API

Slurm provides a REST API daemon named slurmrestd.
Slurmは、slurmrestdという名前のRESTAPIデーモンを提供します。
 This daemon is designed to allow clients to communicate with Slurm via a REST API (in addition to the command line interface (CLI) or C API).
このデーモンは、クライアントが（コマンドラインインターフェイス（CLI）またはC APIに加えて）RESTAPIを介してSlurmと通信できるように設計されています。

Prerequisites

slurmrestd requires additional libraries for compilation:
slurmrestdは、コンパイルのために追加のライブラリを必要とします。

Stateless

Slurmrestd is stateless as it does not cache or save any state between requests.
Slurmrestdは、リクエスト間で状態をキャッシュまたは保存しないため、ステートレスです。
 Each request is handled in a thread and then all of that state is discarded.
各リクエストはスレッドで処理され、その状態はすべて破棄されます。
 Any request to slurmrestd is completely synchronous with the Slurm controller (slurmctld or slurmdbd) and is only considered complete once the HTTP response code has been sent to the client.
slurmrestdへの要求はすべて、Slurmコントローラー（slurmctldまたはslurmdbd）と完全に同期しており、HTTP応答コードがクライアントに送信された後にのみ完了したと見なされます。
 Slurmrestd will hold a client connection open while processing a request.
Slurmrestdは、リクエストの処理中にクライアント接続を開いたままにします。
 Slurm database commands are commited at the end of every request, on the success of all API calls in the request.
Slurmデータベースコマンドは、リクエスト内のすべてのAPI呼び出しが成功すると、すべてのリクエストの最後にコミットされます。

Sites are strongly encouraged to setup a caching proxy between slurmrestd and clients to avoid having clients repeatedly call queries, causing usage to be higher than needed (and causing lock contention) on the controller.
サイトでは、slurmrestdとクライアントの間にキャッシュプロキシを設定して、クライアントがクエリを繰り返し呼び出すことを回避し、コントローラーでの使用量が必要以上に高くなる（およびロックの競合が発生する）ことを強くお勧めします。

Run modes

Slurmrestd currently supports two run modes: inet service mode and listening mode.
Slurmrestdは現在、inetサービスモードとリスニングモードの2つの実行モードをサポートしています。

Inet Service Mode

The Slurmrestd daemon acts as an Inet Service treating STDIN and STDOUT as the client.
Slurmrestdデーモンは、STDINとSTDOUTをクライアントとして扱うInetサービスとして機能します。
 This mode allows clients to use inetd, xinetd, or systemd socket activated services and avoid the need to run a daemon on the host at all times.
このモードでは、クライアントはinetd、xinetd、またはsystemdソケットでアクティブ化されるサービスを使用でき、ホスト上でデーモンを常に実行する必要がありません。
 This mode creates an instance for each client and does not support reusing the same instance for different clients.
このモードでは、クライアントごとにインスタンスが作成され、異なるクライアントで同じインスタンスを再利用することはできません。

Listening Mode

The Slurmrestd daemon acts as a full UNIX service and continuously listens for new TCP connections.
Slurmrestdデーモンは完全なUNIXサービスとして機能し、新しいTCP接続を継続的にリッスンします。
 Each connection is independently authenticated.
各接続は個別に認証されます。

Configuration

slurmrestd can be configured either by environment variables or command line arguments.
slurmrestdは、環境変数またはコマンドライン引数のいずれかで構成できます。
 Please see the doc/man/man1/slurmrestd.1 man page for details.
詳細については、doc / man / man1 /slurmrestd.1のmanページを参照してください。

IPv6 Support

Slurmrestd supports IPv6 clients.
SlurmrestdはIPv6クライアントをサポートします。
 On dual stack systems, it will likely provide the source IP as an IPv6 IP for IPv4 clients .
デュアルスタックシステムでは、IPv4クライアントのIPv6IPとしてソースIPを提供する可能性があります。
 Slurmrestd must still be able to talk to slurmctld and slurmdbd via IPv4.
Slurmrestdは、IPv4を介してslurmctldおよびslurmdbdと通信できる必要があります。

OpenAPI Specification (OAS)

Slurmrestd is compliant with OpenAPI 3.0.2 .
SlurmrestdはOpenAPI3.0.2に準拠しています。
 The OAS can be viewed at the following URLs:
OASは、次のURLで表示できます。

  • /openapi.json
  • /openapi.yaml
  • /openapi/v3

The OAS is designed to be the primary documentation for the request methods.
OASは、リクエストメソッドの主要なドキュメントとなるように設計されています。
 There are several third party tools that automatically generate documentation against the OAS output listed by openapi.tools.
openapi.toolsによってリストされたOAS出力に対してドキュメントを自動的に生成するサードパーティツールがいくつかあります。

To view the currently generated API reference:
現在生成されているAPIリファレンスを表示するには：
 Slurm REST API Reference
Slurm RESTAPIリファレンス

Plugins

As of Slurm 20.11, the REST API uses plugins for authentication and generating content.
Slurm 20.11以降、RESTAPIは認証とコンテンツの生成にプラグインを使用します。
 These plugins can be optionality listed or selected via command line arguments as described in the slurmrestd documentation.
これらのプラグインは、slurmrestdのドキュメントで説明されているように、オプションでリストするか、コマンドライン引数を介して選択できます。

Plugin life cycle

Plugins provided with Slurm in any release are considered supported by that release.
すべてのリリースでSlurmで提供されるプラグインは、そのリリースでサポートされていると見なされます。
 Due to the nature of the plugins, one plugin can be supported accross multiple Slurm releases to ensure (limited) forward client compatibility.
プラグインの性質上、複数のSlurmリリースで1つのプラグインをサポートして、（制限された）フォワードクライアントの互換性を確保できます。
 As the slurmrestd plugins are relatively new, we are currently only explicitly deprecating plugins and expect any plugin not marked for deprecation to continue to exist in the next Slurm release.
slurmrestdプラグインは比較的新しいため、現在、プラグインを明示的に非推奨にしているだけであり、非推奨のマークが付いていないプラグインは、次のSlurmリリースでも引き続き存在すると予想されます。
 When a plugin is marked for removal in the next major Slurm release, the OpenAPI specification dictates that the given plugin will have all of the paths tagged with 

"deprecated": "true"

プラグインが次のメジャーSlurmリリースで削除対象としてマークされると、OpenAPI仕様では、指定されたプラグインに「非推奨」でタグ付けされたすべてのパスが含まれるように指示されます：「true」

Sites are always encouraged to use the latest stable plugin version available for code development.
サイトでは、コード開発に利用できる最新の安定したプラグインバージョンを使用することを常にお勧めします。
 There is no guarantee of compatibility between different versions of the same plugin with clients.
同じプラグインの異なるバージョンとクライアント間の互換性は保証されません。
 Clients should always make sure to validate their code when migrating to newer versions of plugins.
新しいバージョンのプラグインに移行する場合、クライアントは常にコードを検証する必要があります。
 Plugin versions will always be included in the path for every method provided by a given plugin to ensure no two plugins will provide the same path.
プラグインのバージョンは、2つのプラグインが同じパスを提供しないように、特定のプラグインによって提供されるすべてのメソッドのパスに常に含まれます。

As the plugins utilize the Slurm API internally, plugins that existed in previous versions of Slurm should continue to be able to communicate with the two previous versions of Slurm, similar to other components of Slurm.
プラグインは内部でSlurmAPIを利用するため、以前のバージョンのSlurmに存在していたプラグインは、Slurmの他のコンポーネントと同様に、以前の2つのバージョンのSlurmと引き続き通信できるはずです。
 Newer plugins may have required RPC changes which will exclude them from working with previous Slurm versions.
新しいプラグインではRPCの変更が​​必要な場合があり、以前のSlurmバージョンでの作業から除外されます。
 For instance, the openapi/dbv0.0.36 plugin will not be able to communicate with any slurmdbd servers prior to the slurm-20.11 release.
たとえば、openapi / dbv0.0.36プラグインは、slurm-20.11リリースより前のslurmdbdサーバーと通信できません。

As with all other plugins in Slurm, sites are more than welcome to write their own plugins and are suggested to submit them as code contributions via bugzilla, tagged as a contribution.
Slurmの他のすべてのプラグインと同様に、サイトは独自のプラグインを作成することを歓迎し、投稿としてタグ付けされたbugzillaを介してコード投稿として送信することをお勧めします。
 The plugin API provided may change between releases which could cause site specific plugins to break.
提供されるプラグインAPIはリリース間で変更される可能性があり、サイト固有のプラグインが破損する可能性があります。

Security

The Slurm REST API is written to provide the necessary functionality for clients to control Slurm using REST commands.
Slurm REST APIは、クライアントがRESTコマンドを使用してSlurmを制御するために必要な機能を提供するように作成されています。
 It is not designed to be directly internet facing.
インターネットに直接接続するようには設計されていません。
 Only unencrypted and uncompressed HTTP communications are supported.
暗号化されていないHTTP通信と圧縮されていないHTTP通信のみがサポートされています。
 Slurmrestd also has no protection against man in the middle or replay attacks.
Slurmrestdには、中間者攻撃やリプレイ攻撃に対する保護もありません。
 Slurmrestd should only be placed in a trusted network that will communicate with a trusted client.
Slurmrestdは、信頼できるクライアントと通信する信頼できるネットワークにのみ配置する必要があります。

JSON Web Token (JWT) Authentication

slurmrestd supports using JWT to authenticate users.
slurmrestdは、JWTを使用したユーザーの認証をサポートしています。
 JWT can be used to authenticate user over REST protocol.
JWTは、RESTプロトコルを介してユーザーを認証するために使用できます。

  • User Name Header: X-SLURM-USER-NAME
  • JWT Header: X-SLURM-USER-TOKEN
SlurmUser or root can provide alternative user names to act as a proxy for the given user.
SlurmUserまたはrootは、特定のユーザーのプロキシとして機能する代替ユーザー名を提供できます。
 While using JWT authentication, slurmrestd should be run as a unique, unprivileged user and group.
JWT認証を使用している間、slurmrestdは一意の非特権ユーザーおよびグループとして実行する必要があります。
 Slurmrestd should be provided an empty SLURM_JWT environment variable at startup to activate JWT authentication.
Slurmrestdには、JWT認証をアクティブ化するために、起動時に空のSLURM_JWT環境変数を提供する必要があります。
 This will allow users to provide their own JWT tokens while authenticating to the proxy.
これにより、ユーザーはプロキシへの認証中に独自のJWTトークンを提供できます。

When using JWT, it is important that AuthAltTypes=auth/jwt be configured in your slurm.conf for slurmrestd.
JWTを使用する場合、slurmrestdのslurm.confでAuthAltTypes = auth / jwtを構成することが重要です。

Local Authentication

slurmrestd supports using UNIX domain sockets to have the kernel authenticate local users.
slurmrestdは、UNIXドメインソケットを使用してカーネルにローカルユーザーを認証させることをサポートしています。
 slurmrestd must be run as SlurmUser or root to allow multiple different users at the same time but it is not required if users wish to run as only themselves.
slurmrestdは、複数の異なるユーザーを同時に許可するためにSlurmUserまたはrootとして実行する必要がありますが、ユーザーが自分自身としてのみ実行する場合は必要ありません。
 Slurmrestd must be located in the Munge security domain in order to function and communicate with Slurm in local authentication mode.
Slurmrestdは、ローカル認証モードで機能し、Slurmと通信するために、Mungeセキュリティドメインに配置されている必要があります。

Last modified 17 December 2020