cluster: support IngoreInitConfigComps

[Smityz]

What problem does this PR solve?

If we have a large number of tikv-server, it will cost a lot of time(several hours) to generate config

What is changed and how it works?

./tiup-cluster scale-in Kvstore_UAT_0 --node <IP:port> -y --ignore-config-roles tikv

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Code changes

• Has exported function/method change
• Has exported variable/fields change
• Has interface methods change
• Has persistent data change

Side effects

• Possible performance regression
• Increased code complexity
• Breaking backward compatibility

Related changes

• Need to cherry-pick to the release branch
• Need to update the documentation

Release notes:

NONE

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has not been approved.

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Details

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[CLAassistant]

All committers have signed the CLA.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 50.00000% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 39.13%. Comparing base (9e2e464) to head (286e65e).
⚠️ Report is 335 commits behind head on master.

Files with missing lines	Patch %	Lines
pkg/cluster/manager/builder.go	20.00%	3 Missing and 1 partial ⚠️

❗ There is a different number of reports uploaded between BASE (9e2e464) and HEAD (286e65e). Click for more details.

HEAD has 11 uploads less than BASE

Flag	BASE (9e2e464)	HEAD (286e65e)
cluster	9	4
unittest	4	0
playground	3	1

Additional details and impacted files

@@             Coverage Diff             @@
##           master    #1987       +/-   ##
===========================================
- Coverage   57.05%   39.13%   -17.93%     
===========================================
  Files         313      266       -47     
  Lines       33492    29336     -4156     
===========================================
- Hits        19108    11478     -7630     
- Misses      12140    16374     +4234     
+ Partials     2244     1484      -760     

Flag	Coverage Δ
cluster	36.72% <50.00%> (-9.07%)	⬇️
dm	?
playground	14.96% <ø> (+1.39%)	⬆️
tiup	?
unittest	?

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Smityz]

  - Download blackbox_exporter: (linux/amd64) ... Done
  - Download node_exporter: (linux/amd64) ... Done
  - Download alertmanager: (linux/amd64) ... Error
Error: read manifest from mirror(https://tiup-mirrors.pingcap.com/) failed: invalid signature for file root.json: not enough signatures (2) for threshold 3 in root.json

I can't fix this unit test, can someone help me?

[nexustar]

I think we should resolve that it takes a lot of time(several hours) to generate config, rather than provide a flag to ignore it

[Smityz]

I think we should resolve that it takes a lot of time(several hours) to generate config, rather than provide a flag to ignore it

I don't know why we should generate configs in all nodes when scale in. The config seems unchanged. Could you please explain it to me?

[Smityz]

PTAL

[AstroProfundis]

If any PD node is scaled in, we should re-generate configs for all TiKV and TiDB nodes as they are in the startup scripts. And the Prometheus config is always updated if any node is added or removed from the cluster.

I agree that we don't have to regenerate configs for all nodes in some cases, but that could be quite complex to implement, the current approach is a reasonable workaround.

Could you rename the --ignore-components argument to something like --ignore-config-roles to show that it is for configs? And I think it could be better to mark it as hidden as well.

[Smityz]

Thanks for your explanation @AstroProfundis
I think maybe we can disable regenerate configs when TiDB/TiKV scale in/out or prune? I think this operation is safe.

[AstroProfundis]

Sorry for the delay...

I think maybe we can disable regenerate configs when TiDB/TiKV scale in/out or prune?

I agree, and I think TiFlash is also safe to be ignored, but I'm not 100% sure about that...

[Smityz]

In our production environment(only TiKV cluster), I have used this code many times and found nothing unusual, how about adding this feature as optional? Our cluster has hundreds of nodes, and init config for every node when scaling is really slow.

[AstroProfundis]

I agree that adding it as an optional switch for users to decide what components should be ignored when updating configs could be reasonable.

Could you rename the --ignore-components argument to something like --ignore-config-roles to show that it is for configs? And I think it could be better to mark it as hidden as well.

How about like this?

[Smityz]

Have updated name @AstroProfundis
And I don't know what's the meaning of mark it as hidden

[Smityz]

@AstroProfundis It's been a long time, Do you still interested in this PR?