Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tests/node_ops: avoid interference betwen failure injections and ops #20309

Conversation

bashtanov
Copy link
Contributor

@bashtanov bashtanov commented Jun 26, 2024

They can already be separated with a lock, but it's not sufficient. We need certain delay between them.

Fixes #18272

Backports Required

  • none - not a bug fix
  • none - this is a backport
  • none - issue does not exist in previous branches
  • none - papercut/not impactful enough to backport
  • v24.1.x
  • v23.3.x
  • v23.2.x

Release Notes

@bashtanov
Copy link
Contributor Author

/dt

@bashtanov bashtanov force-pushed the test-node-ops-failures-no-interfere branch from b8c0188 to 18b2a4e Compare June 26, 2024 18:34
@bashtanov
Copy link
Contributor Author

/dt

@bashtanov bashtanov force-pushed the test-node-ops-failures-no-interfere branch from 18b2a4e to 3d28155 Compare June 26, 2024 19:45
@bashtanov
Copy link
Contributor Author

/dt

They can already be separated with a lock, but it's not sufficient.
We need certain delay between them.
@bashtanov bashtanov force-pushed the test-node-ops-failures-no-interfere branch from 3d28155 to 308667f Compare June 27, 2024 10:10
@bashtanov
Copy link
Contributor Author

/dt

1 similar comment
@bashtanov
Copy link
Contributor Author

/dt

@bashtanov
Copy link
Contributor Author

test failure unrelated

@bashtanov bashtanov marked this pull request as ready for review June 28, 2024 15:11
@@ -330,6 +332,7 @@ def stop_node(self, idx):
with self.lock:
self.redpanda.remove_from_started_nodes(node)
self.redpanda.stop_node(node)
time.sleep(self.wait_after_stop)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how exactly this fixes the issue? The test failure is a idempotency violation, I thought that would be a code bug in most cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test uses both random failures and node decommissions. The problem was reproduced in the following way:

  1. node 2 was the leader, node 3 was mostly up to date with it, and node 4 was behind
  2. node 2 was restarted, and very shortly after it node 3 got down
  3. node 4 became a candidate and node 2 voted for it because when 2 restarted it could not recover up to the majority_replicated_index point, but rather only till some point below -- is it normal?
  4. so some raft data was lost

@mmaslankaprv
Copy link
Member

i agree with Bharath that the solution from that PR doesn't fixe the issue mentioned in cover letter

@bashtanov bashtanov closed this Jul 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CI Failure (possible idempotency bug) in RandomNodeOperationsTest.test_node_operations
3 participants