Rename Feature Flags to No Return Flag

[eduardomb08]

Is your feature request related to a problem? Please describe.

Yes. After enabling a feature flag in a cluster it is impossible to revert the change. It is necessary to rebuild the cluster. Trying to revert to a previous image resulted in an error message about some incompatibility because of the feature flag.

Describe the solution you'd like

Replace all references to Feature Flags to something like No Return Flags. After all, feature flags are by nature toggled not only from False to True but also the reverse.

Describe alternatives you've considered

Making it possible to disable a feature flag.

Additional context

No response

[mkuratczyk]

Main question is: why would you want to disable it? What happened that you wanted to do that?

While the term "feature flag" is indeed more often used to refer to feature toggles with the option to turn the feature off, in case of RabbitMQ and some other distributed systems, it used to describe flags that indeed can't be reverted: it is purely a mechanism to allow rolling upgrades - already upgraded nodes work in a "compatibility mode" (they don't use the new features/data structures/formats) until all nodes are upgraded and feature flags are enabled.

While the name may not be perfect, "no return flag" would certainly be more confusing.

https://www.rabbitmq.com/feature-flags.html

[eduardomb08]

The issue was that after upgrading to version 3.11, I enabled the single_active_consumer flag cause my whole intent with the upgrade was to test a stream with single active consumer. Shortly after, I realized the Users and Policies tabs under Admin stopped working (see my comment here).. Because of the error, I tried reverting the cluster to a previous image, which is showing to be impossible.

Really frustrating, tbh!

[michaelklishin]

RabbitMQ has never supported downgrades. Feature flags is a modern upgrade mechanism: some changes can be reverted, others cannot.
If a migration deletes or otherwise destructively modifies an on-disk data structure, there is no way this can be reverted.

You probably needed to file this issue to vent because you cannot seriously expect us to rename feature flags to "no return flags".

Perhaps try things on in a non-production cluster.

And those "3.11 management UI issues" should all be addressed in 3.11.13.

[michaelklishin]

If management UI runs into a JS exception on 3.11.13, you need to clear browser cache and local storage, or provide a way to reproduce because I cannot.

[michaelklishin]

We will not be renaming feature flags or making those that cannot be reverted revertable. If you are not sure what a feature flag does or if you can roll out a new release in production, perhaps try things out first in a separate cluster.

I don't see how anything other than more venting can come out of this discussion => locking.

[michaelklishin]

One last thought that has crossed my mind: feature flag state is stored in basic text files, so if a feature flag must be reverted (or "reverted" according to the list of enabled feature flags), it
is possible to roll back all cluster nodes and make older nodes rejoin
the same cluster.

It's a matter of nodes agreeing on the state of a set.

Introducing a CLI command that would override feature flag state like that is likely to repeat the faith of rabbitmqctl force_boot which
is very rarely necessary but some beginners enthusiastically use
to solve any node boot problem without understanding what was going on, like what nodes do after a restart and what it means for certain deployment strategies.

It would take a lot of convincing without unnecessary emotions involved and brazen requests for changes that obviously will not be accepted.