refactor(gluster): keep one cluster's values out of brick_servers #28

Merged
claudiomaradonna merged 1 commit from refactor/brick-servers-tenant-vars into main 2026-10-08 09:18:45 +02:00
Collaborator

Why

group_vars/brick_servers.yml set rpcbind on and narrowed the brick port range to 49152:49161 for every tenant's brick servers, with comments describing one cluster's three single-brick nodes. The shared layer holds only what every tenant should get (AGENTS rule 10). A tenant with more than ten bricks on a node would see a new brick come up Online locally and stay unreachable to its peers, with nothing pointing at the firewall.

What changed

  • The shared file now sets only gluster_enabled, and says that a cluster's own values (rpcbind, a narrower brick range) go in its tenant's inventory as brick_servers group vars. ADVANCED_USAGE's group row says the same.
  • The one tenant with brick servers carries both values, with their reasons, in its own inventory (castrum-fleet commit 91e2c0a).

Verification

  • Every host in every tenant resolves to the same variables before and after (ansible-inventory --host and --list, compared without printing values), so no host changes.
  • make check passed. make test was not run (no podman in the agent sandbox); no role or test changed.

Risks and follow-ups

  • Apply this only once castrum-fleet 91e2c0a is on its main. That push was refused because the branch is protected. A checkout with the new castrum but the old inventory would drop the home brick servers' rpcbind rule and widen their brick range to the role default.
## Why `group_vars/brick_servers.yml` set rpcbind on and narrowed the brick port range to `49152:49161` for every tenant's brick servers, with comments describing one cluster's three single-brick nodes. The shared layer holds only what every tenant should get (AGENTS rule 10). A tenant with more than ten bricks on a node would see a new brick come up Online locally and stay unreachable to its peers, with nothing pointing at the firewall. ## What changed - The shared file now sets only `gluster_enabled`, and says that a cluster's own values (rpcbind, a narrower brick range) go in its tenant's inventory as `brick_servers` group vars. ADVANCED_USAGE's group row says the same. - The one tenant with brick servers carries both values, with their reasons, in its own inventory (castrum-fleet commit `91e2c0a`). ## Verification - Every host in every tenant resolves to the same variables before and after (`ansible-inventory --host` and `--list`, compared without printing values), so no host changes. - `make check` passed. `make test` was not run (no podman in the agent sandbox); no role or test changed. ## Risks and follow-ups - Apply this only once castrum-fleet `91e2c0a` is on its `main`. That push was refused because the branch is protected. A checkout with the new castrum but the old inventory would drop the home brick servers' rpcbind rule and widen their brick range to the role default.
group_vars/brick_servers.yml set rpcbind on and narrowed the brick port
range to 49152:49161 for every tenant's brick servers, with comments
describing one cluster's three single-brick nodes. AGENTS rule 10 keeps
the shared layer to what every tenant should get, and a tenant with
more than ten bricks on a node would have lost its new brick to the
narrow range without a firewall error to point at it.

The shared file now sets only gluster_enabled and says where a
cluster's own values go; ADVANCED_USAGE's group row says the same. The
one tenant with brick servers carries both values, with their reasons,
as brick_servers group vars in its own inventory (fleet repository).

Every host in every tenant resolves to the same variables before and
after (ansible-inventory --host, compared without printing values), so
no host changes.
claudiomaradonna deleted branch refactor/brick-servers-tenant-vars 2026-10-08 09:18:50 +02:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
claudiomaradonna/castrum!28
No description provided.