This section explains how to create pools and manage resources and settings of compute pools in the YTsaurus system using the CLI and web interface as examples.

General information

The YTsaurus system has a mechanism for managing compute pools, enabling pool actions such as:

• Creating.
• Renaming.
• Moving.
• Deleting.
• Changing settings.

You can change the compute pool settings by editing the relevant pool attributes. Attributes that can be edited by the user:

• weight: Manages the share of the parent pool's resources that will go to the current pool.
• max_operation_count: A limit on the number of running (running) operations and operations in the queue (pending).
• max_running_operation_count: A limit on the number of running (running) operations.
• strong_guarantee_resources: A dict describing the pool's guaranteed resources.
• forbid_immediate_operations: Prohibits operations to be run directly in this pool.
• mode: A way of allocating resources between operations in the pool.
• fifo_sort_parameters: Managing the order in which operations are started in fifo pools.
• resource_limits: A dict that sets the upper limits for the resources available to the pool.
• create_ephemeral_subpools: Allows creating ephemeral pools.
• ephemeral_subpool_config: A dictionary describing the configuration of virtual pools.

For more information about the listed attributes, see Pool configuration.

Validating

When validating, YTsaurus checks attribute types, the max_operation_count >= max_running_operation_count limit, the number of tags in the allowed_profiling_tags list (no more than 200), consistency of resource guarantees, and whether there are subpools in fifo pools.

Consistency of resource guarantees means that for each resource, the sum of the descendants' guarantees must not exceed the parent's guarantee. If the subpool has a non-zero guarantee for a specific resource, it must also be set for the parent. The pool is allowed to have a non-zero guarantee on more than one resource.

Access rights

To manage a pool, you need to request access to the pool. You can do this via the YTsaurus web interface.

Pool access rights are managed by users who already have the appropriate access — by default, access is granted to the user who created the pool.

To request access to a pool:

1. Navigate to the pool page from the Scheduling section.
2. Select the ACL tab.
3. Click Request permissions, fill in the form, and click Confirm.

List of allowed pool actions

• To create or delete pool trees, you need the write permission on the root //sys/pool_trees (only for YTsaurus cluster administrators).
• To create pools, you need the write or modify_children permission on the parent pool (granted together with Use access on the parent pool).
• To delete a pool, you need the remove permission on it (granted together with Use access on the parent pool).
• To change user-defined pool attributes, you need the write permission on the pool (granted together with Use access on the parent pool).
• To change all other pool attributes, you need the administer permission (only for YTsaurus cluster administrators).
• To manage operations in this pool and its descendants, you need the manage permission (managing operations means you can perform suspend, resume, and update_operation_parameters operations without being the operation's author).

As an example, consider the project-root pool in the default pool tree.
The required set of permissions for managing sub-pools is shown in the listing:

$ yt get //sys/pool_trees/default/project-root/@acl
[
    {
        "permissions" = [
            "modify_children";
        ];
        "action" = "allow";
        "subjects" = [
            "some_user";
        ];
        "inheritance_mode" = "object_and_descendants";
    };
    {
        "permissions" = [
            "write";
            "remove";
        ];
        "action" = "allow";
        "subjects" = [
            "some_user";
        ];
        "inheritance_mode" = "descendants_only";
    };
]

The user can manage sub-pools but not the project's root pool — they cannot change the guarantee of the project's root pool or other parameters. The permission applies only to the descendants of this pool.

Managing pools via the CLI

Creating a subpool:

yt create scheduler_pool --attributes='{pool_tree=default;name=project-subpool1;parent_name=project-root}'

In the attributes, you can additionally pass the pool attributes and they will be validated. If the validation fails, the object will not be created.

Example of a weight change for the created pool:

yt set //sys/pool_trees/default/project-root/project-subpool1/@weight 10

Initial setting of a pool guarantee provided that the parent has an unallocated guarantee:

yt set //sys/pool_trees/default/project-root/project-subpool1/@strong_guarantee_resources '{cpu=50}'

A specific parameter can be changed to alter a set guarantee:

yt set //sys/pool_trees/default/project-root/project-subpool1/@strong_guarantee_resources/cpu 100

Moving is performed in the standard way:

yt move //sys/pool_trees/default/project-root/project-subpool1 //sys/pool_trees/default/new-project/new-subpool

Renaming via moving is supported.
Validation occurs when moving.

Attributes are set in the standard way:

yt set //sys/pool_trees/default/project_pool/@max_operation_count 10

Validation occurs when setting attributes.

Managing pools via web interface

You can manage pools in the web interface in the Scheduling section.

To create a sub-pool, navigate to the parent pool by clicking its name. Then click the Create pool button, fill in all required fields in the form, and click Confirm.

An example of the pool creation form is shown in the figure.

To edit pool settings, click the pencil icon in the row with the pool name on the right side of the screen, as shown in the figure.

Editable pool settings are divided into groups. The figures show examples of general settings and guaranteed resources, respectively.

In the Resource Limits section, you can set an upper limit for the pool, for example, to prevent the pool from using more than 100 CPU cores. By default, pools have no upper limit; the resources available to a pool are limited by the cluster's capacity.

The Other Settings section contains additional settings, including the option to prohibit running operations in the pool.