Closed dumbbell closed 1 month ago
I agree, they should just be enabled automatically after upgrade. Seen too many upgrades go bad because of it
I'm absolutely not sure where to post this, but I'm having 50/50 success with this postStart k8s hook (where the port is 5672)
Sometimes it works, sometimes it doesn't. How is everyone else "auto-enabling" feature flags?
I'm absolutely not sure where to post this, but I'm having 50/50 success with this postStart k8s hook (where the port is 5672)
Sometimes it works, sometimes it doesn't. How is everyone else "auto-enabling" feature flags?
Maybe you need to sleep a bit after the successful nc?
Using apt packages we cannot even do this and one day rabbitmq is just broken :(
@jflambert I am absolutely positively certain that this project has had GitHub Discussions enabled for close to a couple of years now.
It is unlikely I will implement an auto-enable mechanism because it has too many implications. In the end, I’m in favor of leaving the decision to enable a feature flag to the end user because only they know about the bigger picture of their needs, workload and environment.
Improvements to feature flags are tracked in the following project: https://github.com/orgs/rabbitmq/projects/4/views/1
@kjnilsson would like a way to auto-enable a feature flag that has no visible change to end users, so that they don't have to worry about it. The feature flag should be enabled automatically if arbitrary conditions are met.
The idea we discussed is that such a feature flag would have an additional property to tell it should be auto-enabled. On RabbitMQ node startup, the feature flag subsystem should try to enable such feature flags. If they can't be enabled, that's fine and they are left disabled. This should be quite easy to implement.
In Karl's case, he would like that a feature flag is enabled as soon as all members in a cluster support it. This idea would fit this use case: each node tries to enable it and as soon as the last node is upgrade, it will succeed.