-
Notifications
You must be signed in to change notification settings - Fork 314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Separate Component Version in Cluster #2010
Conversation
[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 The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
|
||
## Motivation | ||
|
||
- New component TiDB Dashboard need to deployed with TiDB but not release with TiDB. Need a way to specify Dashboard version when deployment and upgrade. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect whether TiDB Dashboard is really capable of a standalone version.
This means it is possible that user deploy a TiDB Dashboard with a very old TiDB, for example, TiDB 4.0 with TiDB Dashboard master. I guess this will just make TiDB Dashboard not working at all. It would also be a disaster to make sure that latest TiDB Dashboard is compatible with all existing TiDB cluster versions.
I don't think PM have considered this defect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think use different component for TiDB cluster should not be considered by TiUP PM. Because TiDB cannot ensure different versions can work well together. We should not do this if no one can guarantee the behaviors of a TiDB cluster containing the different versions of components.
Implementing this feature is very easy and the hard part is the different version compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There comes already a demand that TiDB-Dashboard want's to release standalone versions different with TiDB's, so we as a framework need to be prepared with such usage cases.
I do agree we should only enable this config for certain components, at this time, maybe only dashboard, in the Specification
definitions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think use different component for TiDB cluster should not be considered by TiUP PM. Because TiDB cannot ensure different versions can work well together. We should not do this if no one can guarantee the behaviors of a TiDB cluster containing the different versions of components.
Implementing this feature is very easy and the hard part is the different version compatibility.
tiup cluster is not only used in prod environment. I think we cloud only allow user to specify tidb-dashboard version by default. And add a flag like --allow-separate-vertion that allow user to specify version of any component to test or patch component.
|
||
4. if user not specify version, those version has default value latest which means use newest stable version in tiup repo. | ||
|
||
5. maybe add version field to all other component, deafult value is empty which means use global cluster version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As comments above, we should only add component specified version fields to those claims to work with other components on different versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe some version constraint is also needed. For example, TiDB Dashboard vX.X requires TiDB >= vX.X and certain constraint break should not be allowed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe some version constraint is also needed. For example, TiDB Dashboard vX.X requires TiDB >= vX.X and certain constraint break should not be allowed.
maybe we do not need it? if latest tidb-dashboard always support all exist tidb (>=6.2.0). just leave "latest" alisas as tidb-dashboard version. If user upgrade tidb cluster, tidb-dashboard upgrade to latest.If user do not upgrade tidb cluster, tidb-dashboard remains old version. We cloud just to warning user not to upgrade single component if he don't know what will happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is easy to add something like new dashboard do not support old tidb, but not easy to add information like old dashboard do not support new tidb
On TiDB v6.3.0, we will just make TiDB-Dashboard use the same version as TiDB. This RFC will not be implement recently. |
2f3122c
to
7282b44
Compare
[LGTM Timeline notifier]Timeline:
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
New changes are detected. LGTM label has been removed. |
What problem does this PR solve?
What is changed and how it works?
Check List
Tests
Code changes
Side effects
Related changes
Release notes: