The first draft of rep autoexpel

Author: maryiaLichko

doc/reference/configuration/configuration_reference.rst

@@ -3545,6 +3545,7 @@ replication
 The ``replication`` section defines configuration parameters related to :ref:`replication <replication>`.
 
 -   :ref:`replication.anon <configuration_reference_replication_anon>`
+-   :ref:`replication.anon <configuration_reference_replication_autoexpel>`
 -   :ref:`replication.bootstrap_strategy <configuration_reference_replication_bootstrap_strategy>`
 -   :ref:`replication.connect_timeout <configuration_reference_replication_connect_timeout>`
 -   :ref:`replication.election_mode <configuration_reference_replication_election_mode>`
@@ -3600,6 +3601,142 @@ The ``replication`` section defines configuration parameters related to :ref:`re
     | Default: ``false``
     | Environment variable: TT_REPLICATION_ANON
 
+.. _configuration_reference_replication_autoexpel:
+
+.. confval:: replication.autoexpel
+
+    The ``replication.autoexpel`` option designed for managing dynamic clusters using YAML-based configurations.
+    It enables the automatic expulsion of instances that are removed from the YAML configuration.
+
+    Only instances with names that match the specified prefix are considered for expulsion; all others are excluded.
+    Additionally, instances without a persistent name are ignored.
+
+    If an instance is in read-write mode and has the latest database schema, it initiates the expulsion of instances that:
+	- Match the specified prefix
+	- Absent from the updated YAML configuration
+
+    The expulsion process follows the standard procedure, involving the removal of the instance from the ``_cluster`` system space.
+
+    The ``autoexpel`` logic is activated during specific events:
+	- **Startup**. When the cluster starts, ``autoexpel`` checks and removes instances not matching the updated configuration.
+	- **Reconfiguration**. When the YAML configuration is reloaded, ``autoexpel`` compares the current state to the updated configuration and performs necessary expulsions.
+	- ``box.status`` **Watcher Event**. Changes detected by the ``box.status watcher`` also trigger the ``autoexpel`` mechanism.
+
+    New instances
+    ``Autoexpel`` does not take any actions on newly joined instances unless one of the triggering events occurs.
+    This means that an instance meeting the ``autoexpel`` criterion can still join the cluster, but it may be removed
+    later during reconfiguration or on subsequent triggering events.
+
+    ..  NOTE::
+        The ``replication.autoexpel`` option governs the expelling process and is configurable at the replicaset, group, and
+        global levels. It is not applicable at the instance level.
+
+    Configuration fields
+    - **`enabled`** *(boolean, default: `false`)*: enables or disables the ``autoexpel`` logic.
+
+    - **`by`** *(string, default: `nil`)*: specifies the ``autoexpel`` criterion. Currently, only `prefix` is supported and must be explicitly set.
+
+    - **`prefix`** *(string, default: `nil`)*: defines the pattern for instance names that are considered part of the cluster.
+
+      **Example Patterns**:
+      - If instances are prefixed with the replicaset name, set:
+        ``prefix: '{{ replicaset_name }}'``
+      - For instances matching a specific pattern (e.g., `i-\d\d\d`), set:
+        ``prefix: 'i-'``
+
+    **Example**
+
+    1. Create a ``config.yaml`` file with the following content:
+
+    .. code-block:: yaml
+
+        credentials:
+          users:
+            guest:
+              roles: [super]
+
+        replication:
+          failover: manual
+          autoexpel:
+            enabled: true
+            by: prefix
+            prefix: '{{ replicaset_name }}'
+
+        iproto:
+          listen:
+            - uri: 'unix/:./var/run/{{ instance_name }}.iproto'
+
+        groups:
+          g-001:
+            replicasets:
+              r-001:
+                leader: r-001-i-001
+                instances:
+                  r-001-i-001: {}
+                  r-001-i-002: {}
+                  r-001-i-003: {}
+
+
+    This configuration:
+	- Sets up authentication with a guest user assigned the super role.
+	- Enables the autoexpel option to automatically expel instances not present in the YAML file.
+	- Defines instance names based on a prefix pattern: {{ replicaset_name }}.
+	- Lists three instances: r-001-i-001, r-001-i-002, and r-001-i-003.
+
+
+    2. Open terminal window and start three instances using the following commands:
+
+    ``tarantool --name r-001-i-001 --config config.yaml -i``
+
+    ``tarantool --name r-001-i-002 --config config.yaml -i``
+
+    ``tarantool --name r-001-i-003 --config config.yaml -i``
+
+    3. Edit ``config.yaml`` and remove the following entry for ``r-001-i-003``:
+
+    ``r-001-i-003: {}``
+
+
+    The updated ``config.yaml`` should look like this:
+
+    .. code-block:: yaml
+
+        groups:
+          g-001:
+            replicasets:
+              r-001:
+                leader: r-001-i-001
+                instances:
+                  r-001-i-001: {}
+                  r-001-i-002: {}
+
+    Save the file.
+
+    4. For the leader instance (``r-001-i-001``), check the _cluster space:
+
+        ..  admonition:: Info
+        :class: fact
+
+        The ``_cluster`` system space in Tarantool stores metadata about all instances currently recognized as part of the cluster.
+        It shows which instances are registered and active.
+
+    You should see ``r-001-i-003`` still listed in the ``_cluster`` system space.
+
+    5. Reload the configuration:
+
+    .. code-block:: lua
+
+        config = require('config')
+            config:reload()
+
+    6. Verify the changes:
+
+    ``box.space._cluster:fselect()``
+
+    After the reload, ``r-001-i-003`` should no longer appear in the ``_cluster`` system space.
+
+
+
 .. _configuration_reference_replication_bootstrap_strategy:
 
 .. confval:: replication.bootstrap_strategy