HOSTED-POWER
commented
10 months ago I agree, they should just be enabled automatically after upgrade. Seen too many upgrades go bad because of it
Open dumbbell opened 2 years ago
HOSTED-POWER
commented
10 months ago I agree, they should just be enabled automatically after upgrade. Seen too many upgrades go bad because of it
jflambert
commented
8 months ago 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?
HOSTED-POWER
commented
8 months ago 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 :(
michaelklishin
commented
8 months ago @jflambert I am absolutely positively certain that this project has had GitHub Discussions enabled for close to a couple of years now.
@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.