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

Khepri: Mark khepri_db feature flag as stable #12682

Draft
wants to merge 27 commits into
base: main
Choose a base branch
from

Conversation

dumbbell
Copy link
Member

@dumbbell dumbbell commented Nov 7, 2024

Why

The intent is to have it stable and enabled by default for new deployment in RabbitMQ 4.1.x.

To prepare for this goal, it is time to mark the feature flag as stable to let us iron out the library and its integration into RabbitMQ.

This is not a commitment at this stage: we will revisit this near the beginning of the release cycle and commit to it or revert to experimental.

@dumbbell dumbbell self-assigned this Nov 7, 2024
@dumbbell dumbbell force-pushed the mark-khepri_db-as-stable branch 3 times, most recently from 0ae5831 to dffcf0c Compare November 11, 2024 11:31
@mergify mergify bot added the make label Nov 11, 2024
@michaelklishin michaelklishin changed the title Khepri: Mark khepri_db as stable 4.1: Khepri: Mark khepri_db feature flag as stable Nov 13, 2024
@michaelklishin michaelklishin added this to the 4.1.0 milestone Nov 13, 2024
@dumbbell dumbbell changed the title 4.1: Khepri: Mark khepri_db feature flag as stable Khepri: Mark khepri_db feature flag as stable Nov 13, 2024
@mergify mergify bot added the bazel label Nov 14, 2024
[Why]
The intent is to have it stable and enabled by default for new
deployment in RabbitMQ 4.1.x.

To prepare for this goal, it is time to mark the feature flag as stable
to let us iron out the library and its integration into RabbitMQ.

This is not a commitment at this stage: we will revisit this near the
beginning of the release cycle and commit to it or revert to
experimental.
…gs_on_init`

[Why]
We already support that from the environment variable, it is easy to add
to the configuration setting.
[Why]
With `khepr_db` enabled by default, we need another way to disable it to
select Mnesia instead.

[How]
For Khepri, we force the `khepri_db` feature flag. For Mnesia, we force
an empty list, meaning all stable feature flags are disabled by default.

Testsuites will have to enable whatever feature flags they need, though
they should already do that.

While here, change `rjms_topic_selector_SUITE` to only choose Khepri
without specifying any feature flags.
[Why]
We want to disconnect from the remote cluster nodes we tried to join
after a failure to join because it may impact peer discovery when the
local node is restarted (as a standalone node).

In particular, it may trigger the recovery code of peer discovery that
tries to repair a cluster after a node lost its disk entirely.

It could also affect the remote cluster as well.
This reverts commit dce5a08.
…ing it from cluster

[Why]
We want to disconnect a node that was just reset from the remote cluster
nodes because it may impact peer discovery when the local node is
restarted (as a standalone node).

In particular, it may trigger the recovery code of peer discovery that
tries to repair a cluster after a node lost its disk entirely.

It could also affect the remote cluster as well.
…er removing it from cluster"

This reverts commit 50aec18.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

2 participants