Provide support for rollbacks during upgrades without using blue-green deployment

[agapebondservant]

We would like to request support for a more streamlined approach for backups and restores that will allow us to perform rollbacks during upgrades (without having to resort to blue-green deployments).

When upgrading our RabbitMQ clusters, we do an in-place upgrade with no blue-green deployments due to resource constraints. Since rollbacks are not supported out of the box, we can only implement a fix-forward approach for any issues we might encounter, which is risky. Also, it is worth noting that inadvertently deleting the RMQ operators also deletes the CRD objects, which we don’t have backed up. As such, we request that a rollback capability be provided for future RMQ upgrades.

[Zerpet]

Since rollbacks are not supported out of the box, we can only implement a fix-forward approach for any issues we might encounter, which is risky.

You can rollback to a previous minor as long as you have not enabled all the feature flags of the new minor e.g. you can rollback 3.11 -> 3.10, as long as you have not enabled all feature flags in 3.11.

Also, it is worth noting that inadvertently deleting the RMQ operators also deletes the CRD objects, which we don’t have backed up.

That's upstream Kubernetes behaviour, there's not much we can do about it.

What rollback capabilities would you like to see in this Operator?