✅ Deploy Preview for cubefs-check ready!

Name	Link
🔨 Latest commit	ce18fef
🔍 Latest deploy log	https://app.netlify.com/sites/cubefs-check/deploys/65d85733798af30008dbac6d
😎 Deploy Preview	https://deploy-preview-3016--cubefs-check.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Codecov Report

Attention: Patch coverage is 21.39175% with 305 lines in your changes are missing coverage. Please review.

Project coverage is 41.99%. Comparing base (4c1ca65) to head (ce18fef).
Report is 1 commits behind head on master.

@@            Coverage Diff             @@
##           master    #3016      +/-   ##
==========================================
+ Coverage   41.95%   41.99%   +0.03%     
==========================================
  Files         577      577              
  Lines      119055   119381     +326     
==========================================
+ Hits        49946    50129     +183     
- Misses      64831    64974     +143     
  Partials     4278     4278              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

It's a really good and big job, and maybe you should consider the process of upgrading an old cluster because the default values for raftport and replica port are 0 when the older nodes were registered. This could potentially cause issues.

It's a really good and big job, and maybe you should consider the process of upgrading an old cluster because the default values for raftport and replica port are 0 when the older nodes were registered. This could potentially cause issues.

I have made some attempts to resolve the compatibility issues when upgrading the old version.I have finished the dataNode part, but I think it has something wrong and there is still a state inconsistency problem when synchronizing raft information.The scenario I tested was to restart all the Masters first, and then restart the dataNodes one by one.
I think I need some help and suggestions for improvement, and I will finish the metaNode part after that.

The problem I encounter now is that after dataNodes are restarted one by one, although the META information in the locally stored dp file can be updated to the new version with port information, the META information may not be correctly changed when other member changes such as del-replica are performed.

I found that in the branch <develop-hybridcloud-lifecycle>, the branch also changes the structure of dataNode with adding mediaType when it adds the storage tiering function. How does that solve the problem in the process of upgrading an old cluster?

I think the problem mentioned doesn't exist anymore, but I'm not sure if there are other problems because I haven't fully understood the mechanism here.

I found that in the branch , the branch also changes the structure of dataNode with adding mediaType when it adds the storage tiering function. How does that solve the problem in the process of upgrading an old cluster?
in branch , filed mediaType is only on the master, there no filed added on datanode