Deuxfleurs/garage
31
61
Fork 80
Code Issues 91 Pull requests 14 Releases 31 Wiki Activity

fix crash in layout computation when changing all nodes of a zone to gateway mode #937

Merged
lx merged 1 commit from baptiste/garage:fix_layout_crash into main 2025-02-19 17:09:11 +00:00
Conversation 1 Commits 1 Files changed 1 +10 -4
baptiste commented 2025-01-27 18:41:06 +00:00
Owner
Copy link

This change is probably not a proper fix, somebody with more expertise on
this code should look at it.

Here is how to reproduce the crash:

  • start with a layout with two zones
  • move all nodes of a zone to gateway mode: garage layout assign fea54bcc081f318 -g
  • garage layout show will panic with a backtrace

Fortunately, the crash is only on the RPC client side, not on the Garage
server itself, and garage layout revert still works to go back to the
previous state.

As far as I can tell, this bug is present since Garage 0.9.0 which
includes the new layout assignation algorithm:

#296

This change is probably not a proper fix, somebody with more expertise on this code should look at it. Here is how to reproduce the crash: - start with a layout with two zones - move all nodes of a zone to gateway mode: `garage layout assign fea54bcc081f318 -g` - `garage layout show` will panic with a backtrace Fortunately, the crash is only on the RPC client side, not on the Garage server itself, and `garage layout revert` still works to go back to the previous state. As far as I can tell, this bug is present since Garage 0.9.0 which includes the new layout assignation algorithm: https://git.deuxfleurs.fr/Deuxfleurs/garage/pulls/296
baptiste added 1 commit 2025-01-27 18:41:06 +00:00
WIP: fix crash in layout computation when changing all nodes of a zone to gateway mode
All checks were successful
ci/woodpecker/pr/debug Pipeline was successful
Details
6d798c640f 
This change is probably not a proper fix, somebody with more expertise on
this code should look at it.

Here is how to reproduce the crash:

- start with a layout with two zones
- move all nodes of a zone to gateway mode: `garage layout assign fea54bcc081f318 -g`
- `garage layout show` will panic with a backtrace

Fortunately, the crash is only on the RPC client side, not on the Garage
server itself, and `garage layout revert` still works to go back to the
previous state.

As far as I can tell, this bug is present since Garage 0.9.0 which
includes the new layout assignation algorithm:

  #296
lx approved these changes 2025-02-14 12:39:00 +00:00
lx left a comment
Owner
Copy link

I think it's fine to merge this as-is

I think it's fine to merge this as-is
src/rpc/layout/version.rs
@ -650,8 +650,11 @@ impl LayoutVersion {
let mut cost = CostFunction::new();
for (p, assoc_p) in prev_assign.iter().enumerate() {
for n in assoc_p.iter() {
lx commented 2025-02-14 12:35:28 +00:00
Owner
Copy link

Maybe add a // FIXME comment to indicate that we are not sure that this is the correct solution.

Even if this is the "wrong" solution, I don't think it will have a big impact. At worse, too much data will be migrated between nodes, but I don't think it can crash Garage or put it in an invalid state.

Maybe add a `// FIXME` comment to indicate that we are not sure that this is the correct solution. Even if this is the "wrong" solution, I don't think it will have a big impact. At worse, too much data will be migrated between nodes, but I don't think it can crash Garage or put it in an invalid state.
src/rpc/layout/version.rs
@ -754,2 +757,2 @@
old_zones_of_p
.push(zone_to_id[self.expect_get_node_zone(&self.node_id_vec[*n])]);
if let Some(&zone_id) =
zone_to_id.get(self.expect_get_node_zone(&self.node_id_vec[*n]))
lx commented 2025-02-14 12:36:22 +00:00
Owner
Copy link

This one does not impact correctness of the layout computation, at worse wrong statistics will be shown but I think that's ok to leave for a future issue if it happens.

This one does not impact correctness of the layout computation, at worse wrong statistics will be shown but I think that's ok to leave for a future issue if it happens.
lx added the
kind
correctness
scope
ops
 labels 2025-02-14 12:52:21 +00:00
Mendes commented 2025-02-16 12:48:39 +00:00
Member
Copy link

The issue comes from the fact if node was used in the previous assignment but becomes a gateway node, it still appears in prev_assign (with an index >= self.nongateway_nodes().len()).

I think too that the proposed fix is fine to be merged as is. It does not introduce any suboptimality since it's implicit consequence is to ignore gateway node in the last optimization step.

A further fix would be to explicitly exclude gateway node from prev_assign and old_assignment_opt by editing the last loop of update_node_id_vec(...). I can find some time to do it.

The issue comes from the fact if node was used in the previous assignment but becomes a gateway node, it still appears in `prev_assign` (with an index >= `self.nongateway_nodes().len()`). I think too that the proposed fix is fine to be merged as is. It does not introduce any suboptimality since it's implicit consequence is to ignore gateway node in the last optimization step. A further fix would be to explicitly exclude gateway node from `prev_assign` and `old_assignment_opt` by editing the last loop of `update_node_id_vec(...)`. I can find some time to do it.
❤️ 1
lx changed title from WIP: fix crash in layout computation when changing all nodes of a zone to gateway mode to fix crash in layout computation when changing all nodes of a zone to gateway mode 2025-02-19 17:09:06 +00:00
lx merged commit 1cb0ae10a8 into main 2025-02-19 17:09:11 +00:00
maximilien deleted branch fix_layout_crash 2025-02-19 21:07:42 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
lx
Labels
Clear labels   
action
check-aws
The behaviour should be checked against AWS S3

  
action
discussion-needed
We need to discuss if the feature is desirable and/or better specify the envisioned behavior or technical implementation

  
action
for-external-contributors
Core team does not plan working on this in the near future however an external contribution will be reviewed & merged

  
action
for-newcomers
An issue that should be newcomer friendly.

  
action
more-info-needed
More information is needed to investigate this issue

  
action
need-funding
This issue represents lots of work, we need to find money to pay our core team work

  
action
triage-required
It's not very clear what we want to do with this issue yet, more thoughts is required

  
kind
correctness
Issues of theoretical correctness that may impact edge-case scenarios

  
kind/experimental

PRs implementing experimental features / features used only for debugging

  
kind
ideas
For abstract ideas/proposal to make Garage better, to better communicate our not yet achieved aims

  
kind
improvement
Feature requests that do not fall in other categories

  
kind
performance
Deceptive performance observed OR idea to improve performances

  
kind
testing
Functional tests, integration tests, Jepsen, etc.

  
kind
usability
Propositions to make Garage easier to operate, by improving error reporting, CLI, etc.

  
kind
wrong-behavior
Unintended behavior

  
prio
critical
Could impact integrity or availability of production clusters

  
prio
low
For issues that we don't want to spend time on until made absolutely necessary

  
scope
admin-api
Issues concerning the administration API

  
scope
background-healing
Background healing covers repair tasks, anti-entropy, merkle trees, etc. ; everything related to replicating data appropriately.

  
scope
build
Issues with Nix, Drone, Rust Compiler, etc.

  
scope
documentation

  
scope
k8s
Kubernetes related, including Helm Charts

  
scope
layout
Linked to the cluster layout and storage management

  
scope
metadata
Metadata Engine (LMDB, sqlite, etc.)

  
scope
ops
Operations related to operations/maintenance issue, tooling related (like CLI missing info ; impossible, too dangerous, too complicated migration, etc.)

  
scope
rpc
Linked to RPC

  
scope
s3-api
Related to the S3 API (especially compatibility issues).

  
scope
security
Cryptography-related, auth-related, authorization-related issues

  
scope
telemetry
OpenTelemetry (traces, metrics, etc.)

No labels
action
check-aws
action
discussion-needed
action
for-external-contributors
action
for-newcomers
action
more-info-needed
action
need-funding
action
triage-required
kind
correctness
kind/experimental
kind
ideas
kind
improvement
kind
performance
kind
testing
kind
usability
kind
wrong-behavior
prio
critical
prio
low
scope
admin-api
scope
background-healing
scope
build
scope
documentation
scope
k8s
scope
layout
scope
metadata
scope
ops
scope
rpc
scope
s3-api
scope
security
scope
telemetry
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
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: Deuxfleurs/garage#937
No description provided.
Delete branch "baptiste/garage:fix_layout_crash"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?