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.

Sign up for GitHub

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

Jump to bottom

Make it hard to accidentally enable an experimental feature flag #11998

Merged
merged 5 commits into from
Aug 19, 2024
Merged

Make it hard to accidentally enable an experimental feature flag #11998

merged 5 commits into from
Aug 19, 2024

Conversation

mkuratczyk
Copy link
Contributor

@mkuratczyk mkuratczyk commented Aug 14, 2024 •
edited
Loading

Currently it's easy to enable an experimental feature flag like khepri_db by accident. Given the operation is irreversible, this leads to serious consequences when done in a production environment.

This PR implements the following changes:

  • Management UI
    • Split the feature flags page into two tables - first with all but experimental feature flags, the second with only the experimental flags (and a warning)
    • To enable an experimental feature flag, a checkbox needs to be toggled first
  • CLI
    • rabbitmqctl enable_feature_flag khepri_db won't work unless a new flag --experimental is provided
Screenshot 2024-08-14 at 12 19 57

@mkuratczyk mkuratczyk marked this pull request as draft August 14, 2024 10:41
@mkuratczyk mkuratczyk force-pushed the experimental-ff-safeguards branch from a8da7bc to c55195e Compare August 14, 2024 10:58
@mkuratczyk mkuratczyk marked this pull request as ready for review August 14, 2024 13:13
@dumbbell
Copy link
Member

dumbbell commented Aug 14, 2024 •
edited
Loading

What about naming the CLI flag --experimental to make sure the user knows it’s an experimental feature flag?

Also, I feel that --force is too generic and could mean many things. I could interpret it as "I want this feature flag to be enabled even if some nodes are not running in the cluster" (which is denied today for instance).

@michaelklishin
Copy link
Member

I agree with @dumbbell and would use --experimental instead of --force.

@michaelklishin michaelklishin force-pushed the experimental-ff-safeguards branch from c55195e to 70efb12 Compare August 15, 2024 18:57
@michaelklishin
Copy link
Member

The forced push was a rebase.

@mkuratczyk mkuratczyk force-pushed the experimental-ff-safeguards branch from 70efb12 to e9d4fa2 Compare August 19, 2024 07:01
@mkuratczyk
Copy link
Contributor Author

I've renamed the flag and slightly changed the error message (+rebase)

@mkuratczyk mkuratczyk force-pushed the experimental-ff-safeguards branch from e9d4fa2 to 86446c1 Compare August 19, 2024 07:35
@mkuratczyk
Copy link
Contributor Author

Thanks for the feedback, I've pushed another commit fixing all the issues you pointed out. One question that came to mind is what should happen when rabbitmqctl enable_feature_flag --experimental all is invoked. Currently it still won't enable experimental flags and while intuitively, it should, given the goal of this PR is to prevent accidental enablement of experimental features, I feel like ignoring --experimental when all is used is fine. I can easily be persuaded though. Thoughts?

@dumbbell
Copy link
Member

Instead of ignoring, I think we should either do what it says (enable everithing including experimental feature flags), or reject the command with an error.

As you said, given the goal, I would problably reject the command because the risks will be very specific to each experimental feature flag.

@mkuratczyk mkuratczyk force-pushed the experimental-ff-safeguards branch from cb32f8f to bd6f1b5 Compare August 19, 2024 10:47
@mkuratczyk
Copy link
Contributor Author

--experimental is now rejected when all flags are to be enabled. Commit message improved

@mkuratczyk mkuratczyk requested a review from dumbbell August 19, 2024 14:02
@michaelklishin michaelklishin force-pushed the experimental-ff-safeguards branch from bd6f1b5 to 396ad7a Compare August 19, 2024 17:41
@michaelklishin
Copy link
Member

The forced push was a rebase.

@michaelklishin
Copy link
Member

AWS peer discovery tests occasionally fail for branches and then succeed once merged :(

@michaelklishin michaelklishin added this to the 4.0.0 milestone Aug 19, 2024
@michaelklishin michaelklishin merged commit 24b4371 into main Aug 19, 2024
196 of 197 checks passed
@michaelklishin michaelklishin deleted the experimental-ff-safeguards branch August 19, 2024 19:45
@mergify mergify bot mentioned this pull request Aug 19, 2024
Merged
michaelklishin added a commit that referenced this pull request Aug 19, 2024
@michaelklishin
Merge pull request #12058 from rabbitmq/mergify/bp/v4.0.x/pr-11998
d5cf986 
Make it hard to accidentally enable an experimental feature flag (backport #11998)
@mergify mergify bot mentioned this pull request Aug 19, 2024
Merged
michaelklishin added a commit that referenced this pull request Aug 19, 2024
@michaelklishin
Merge pull request #12059 from rabbitmq/mergify/bp/v3.13.x/pr-12058
8b13372 
Make it hard to accidentally enable an experimental feature flag (backport #11998) (backport #12058)
@the-mikedavis the-mikedavis mentioned this pull request Aug 20, 2024
Merged
This was referenced Aug 20, 2024
Merged
Merged
@michaelklishin michaelklishin mentioned this pull request Nov 21, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@michaelklishin michaelklishin michaelklishin approved these changes

@dumbbell dumbbell Awaiting requested review from dumbbell

Assignees
No one assigned
Labels
backport-v3.13.x backport-v4.0.x
Projects
None yet
Milestone
4.0.0
Development

Successfully merging this pull request may close these issues.
3 participants
@mkuratczyk @dumbbell @michaelklishin