node-clean-data.yml

Overview

The node-clean-data.yml file is an automation playbook designed to manage and reset data on block keeper nodes within a distributed system. It primarily focuses on restarting block keeper services with options to delete existing data, control service startup, and enable fast update modes. This playbook is intended to be executed on a defined group of hosts, allowing systematic and consistent data cleanup operations across the targeted nodes.

Purpose and Functionality

Resets the block keeper services data on specified hosts.
Supports conditional deletion of data before service restart.
Controls whether services should be started automatically after reset.
Enables a fast update mode to optimize the reset process.
Uses the block-keeper role to encapsulate the tasks related to block keeper service management.

Playbook Structure and Parameters

Key	Description
name	Describes the playbook task: "reset block keeper services data".
`gather_facts`	Disabled (`no`) to speed up playbook execution when system facts are not required.
`hosts`	Target hosts for the playbook. Defaults to `block_keepers` group if `target` variable is unset.
`become`	Enables privilege escalation to run tasks as a superuser (`yes`).
`any_errors_fatal`	Ensures that any error during execution halts the entire playbook run (`true`).
`vars`	Defines variables controlling data deletion, service startup, and update mode.
roles	Specifies the `block-keeper` role to execute the relevant service management tasks.

Variables

DELETE_DATA (boolean):
When set to yes, instructs the playbook to delete existing block keeper data before restarting the services.
DO_START (boolean):
Controls whether the block keeper services should be started after the reset procedure. no means services remain stopped.
FAST_UPDATE (boolean):
Enables a fast update mode to speed up the reset process, possibly by skipping non-essential steps or optimizing operations.

Hosts Specification

The playbook targets the hosts in the block_keepers group by default. However, this can be overridden by providing a target variable during execution, allowing flexibility to run on different or specific nodes.

Role Interaction: `block-keeper`

This playbook delegates the execution of detailed tasks to the block-keeper role. This role is responsible for:

Managing the lifecycle of block keeper services.
Performing data deletion based on the DELETE_DATA flag.
Controlling service start or stop according to DO_START.
Applying optimization strategies when FAST_UPDATE is enabled.

This separation of concerns allows the playbook to serve as a high-level orchestrator, while the role encapsulates the implementation specifics.

Usage Example

To run this playbook on the default group (block_keepers), with data deletion enabled but without starting the services:

ansible-playbook node-clean-data.yml

To override the target hosts and enable service startup:

ansible-playbook node-clean-data.yml -e "target=custom_block_keepers DO_START=yes"

Implementation Details

The playbook disables fact gathering to reduce execution time, assuming that system facts are not necessary for the reset operation.
Privilege escalation is enabled to ensure the playbook has sufficient permissions to delete data and manage services.
The any_errors_fatal: true setting enforces strict error handling, stopping the playbook on any failure to prevent inconsistent states.
Variables are predefined with sensible defaults but are designed to be overridden at runtime to provide flexibility.

Interaction with Other Components

The playbook interacts primarily with the nodes grouped under block_keepers, which are part of the broader system managing block data.
The block-keeper role encapsulates all the operational tasks, making this playbook an entry point for block data reset workflows.
It can be integrated into larger automation frameworks or deployment pipelines to maintain block keeper nodes' data consistency.

Mermaid Diagram

flowchart TD
A[Start Playbook] --> B{Gather Facts?}
B -- No --> C[Set Variables DELETE_DATA, DO_START, FAST_UPDATE]
C --> D["Select Hosts (target or block_keepers)"]
D --> E[Execute block-keeper Role]
E --> F{DELETE_DATA == yes?}
F -- Yes --> G[Delete Block Keeper Data]
F -- No --> H[Skip Data Deletion]
G --> I{DO_START == yes?}
H --> I
I -- Yes --> J[Start Block Keeper Services]
I -- No --> K[Keep Services Stopped]
J --> L{FAST_UPDATE == yes?}
K --> L
L -- Yes --> M[Perform Fast Update Workflow]
L -- No --> N[Perform Standard Update Workflow]
M --> O[End Playbook]
N --> O

The above flowchart outlines the primary workflow of the playbook, illustrating decision points based on variable settings and the delegation to the block-keeper role for task execution.