Revert "HDDS-5740. Enable ratis by default for SCM."

[adoroszlai]

What changes were proposed in this pull request?

Revert #2637. The PR was merged regardless of my concern about changing the default setting without providing seamless upgrade path.

It turns out that enabling Ratis by default is indeed causing problems during upgrade. SCM fails to start with:

Configuration ozone.scm.ratis.enable cannot be used until SCM upgrade has been finalized

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-5740

How was this patch tested?

Regular CI:
https://github.com/adoroszlai/hadoop-ozone/actions/runs/2237408109

[mukul1987]

@adoroszlai I agree that scm ha should not be enabled by default for upgrade. but for other profiles i feel we can still enable scm ha ?

Also, can you please include the problem faced during upgrade in the description ?

[adoroszlai]

@mukul1987 SCM HA is definitely recommended for new deployments. Please correct me if I'm wrong, but my understanding is that simply enabling Ratis for single-node SCM is not SCM HA, as that requires multiple nodes and explicit configuration.

[errose28]

When upgrading from an old version to a version supporting SCM HA, none of the SCM HA configs are allowed to be turned on to prevent writing incompatible data before finalization. What happened with the original change was when a non-Ratis SCM was upgraded to a version supporting SCM HA, the ratis enabled flag was automatically set to true. The upgrade framework stopped this before any changes could be made, hence all pre-SCM HA clusters upgraded will fail immediately on startup with the message: Configuration ozone.scm.ratis.enable cannot be used until SCM upgrade has been finalized.
For the user to proceed, the config must be manually set to true and the cluster restarted, poor experience IMO. The upgrade acceptance tests correctly flagged this as incompatible, but they were modified in the original PR to mask the issue.

I am +1 for reverting the change for now to get the incompatibility out of master. However, I see @mukul1987's point that for new clusters, at least 1 node Ratis for SCM would be the preferred default. I think we can come up with a way to do this in a follow-up PR.

[adoroszlai]

I am +1 for reverting the change for now to get the incompatibility out of master. However, I see @mukul1987's point that for new clusters, at least 1 node Ratis for SCM would be the preferred default. I think we can come up with a way to do this in a follow-up PR.

I agree: if enabling SCM Ratis for single node has benefits, we can have an improvement Jira for that. But it is totally out of scope for this revert, as the original change is clearly breaking upgrades.

information provided, change request out of scope

[adoroszlai]

Thanks @errose28, @mukul1987 for the review.