It might be helpful to briefly explain that volume I/O won’t be affected during this transition, even though it has already been covered elsewhere.

In general, in addition to the error message at runtime via status.ErrorMessage, any errors should also be logged as system events or conditions, if possible, as these provide users with a clearer understanding of the system's status. This is more related to implementation though.

We can change the status to

status:
  state:
  conditions:
    - <condition name>:
      status:
      reason:
      message:

However, I tried to use condition and could not find a better name for the condition. Any suggestion? In addition, for the upgrade status, condition seems redundant because the message is already set to status.Message. That's why I don't use condition here.

Conditions can be used to represent mandatory requirements for the upgrade, rather than representing upgrade status.

How about using DefaultImageOnAllNodesReady as the condition for indicating the readiness of the default image?

Does this mean the unknown nodes will be silently filtered? Throwing errors is recommended, as it informs users that the nodes should match those in the cluster.

What does unknown nodes mean?

What I’m asking is that users might add nodes to spec.nodes that don’t actually exist in the cluster. In this case, the upgrade should not be started and allowed.

However, you mentioned in another comment, spec.nodes is immutable, so we should decide the content of it. Then, why do need these two if conditions?

Then, why do need these two if conditions?

Ideally, we should upgrade all nodes cluster, but the design allows users to upgrade some nodes in the cluster according to users' upgrade plan.

Then, we might need to ensure the following items.

• All nodes should be eventually upgraded to the same IM version before the next upgrade to prevent IM version drift.
• If some nodes added by users in spec.nodes are not recognized, the upgrade should be avoided until spec.nodes is corrected by the users.

All nodes should be eventually upgraded to the same IM version before the next upgrade to prevent IM version drift.

We need to add the pre-upgrade check.

Should spec.nodes be immutable for the node once the node upgrade has started, or should we allow mutations in case we support upgrade cancellation? It’s suggested to keep the scenario simple initially.

spec.nodes is immutable. upgrade cancellation is not explicitly supported. For now, if an upgrade is stuck, user can directly delete the dataEngineUpgradeManager resource if it really needs to be caneclled.

Then, this flow should be explained, as this is a valid case for us.

Since the upgrade is node-based, the process for recovering from an error during the status transition (before the node upgrade reaches 'completed') needs to be clarified.

If a volume on the upgrading node is somehow stuck, the nodeDataEngineUpgrade.status.state will be stuck in upgrading state and won't be in an error state, so user needs to resolve the issue, and the node upgrade can continue. Currently, the error message will be set in the status.Message, so the status is

status:
  state: upgrade
  message: an error is found.....

If nodeDataEngineUpgrade.status.state is in error state, it won't be recovered from the error. User needs to recreate a DataEngineUpgradeManager for a new upgrade.

Sounds good. Let's also briefly explain this flow.