[Improvement] revision hash collision

[LuckyGrx]

Is your improvement request related to a problem? Please describe.

Kubeblocks generates a new version revision hash based on the podTemplate that filters in-place update fields and a fixed number of conflict counts (0). Theoretically, different podTemplates can generate the same revision hash, which may lead to instances that should be rebuilt being mistakenly judged as not needing an upgrade. Is there a plan to completely resolve this issue?

If this is a new function, please describe the motivation and goals.
A clear and concise description of why you want to happen, link the design doc if possible

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or functions you've considered.

Additional context
Add any other context or screenshots about the improvement request here.

[shanshanying]

Hi @LuckyGrx

Thanks for raising the issue.

Can you provide some examples or cases to illustrate the issue ?

[LuckyGrx]

There are no specific online cases yet, I only discovered this issue while analyzing this part of the code. The problem scenario is as follows:

When the business upgrades an instanceset, it triggers the use of the NewRevision method to generate a revision hash as the new version. However, the output of this method only depends on the input podTemplate (the other input, collisionCount, is fixed at 0). Different podTemplates have a low probability (1 in 10 million) of generating the same revision hash. The business intends to trigger instance rebuilding by adjusting the podTemplate, but the instanceset controller determines in the getPodUpdatePolicy method that no upgrade is needed. @shanshanying

[LuckyGrx]

@shanshanying

[github-actions]

This issue has been marked as stale because it has been open for 30 days with no activity