*: support tso gRPC interfaces #5852
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. |
|
@binshi-bing PTAL |
Codecov ReportBase: 75.42% // Head: 74.76% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #5852 +/- ##
==========================================
- Coverage 75.42% 74.76% -0.67%
==========================================
Files 337 339 +2
Lines 34123 34149 +26
==========================================
- Hits 25736 25530 -206
- Misses 6163 6421 +258
+ Partials 2224 2198 -26
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
| @@ -139,6 +139,8 @@ type Client interface { | |||
| KeyspaceClient | |||
| // ResourceManagerClient manages resource group metadata and token assignment. | |||
| ResourceManagerClient | |||
| // TsoClient manages TSO data. | |||
| TsoClient | |||
There was a problem hiding this comment.
Maybe it's arguable to say whether we should use TSO rather than Tso 👀.
| data := typeutil.Uint64ToBytes(request.GetTimestamp()) | ||
| txn := kv.NewSlowLogTxn(client) | ||
| resp, err := txn. | ||
| Then(clientv3.OpPut(key, string(data))). |
There was a problem hiding this comment.
Do we need to compare the old one before putting in a new TSO to prevent it from fallback?
There was a problem hiding this comment.
IMO, this part of logic will be done by the TSO service itself. The API service only needs to provide the storage interface.
There was a problem hiding this comment.
I'm wondering whether there will be a case in that different TSO services update the same key at the same time without knowing each other, maybe we should provide an option in the request to determine whether the check should be done. Otherwise, the services need to maintain some kind of mechanism to make sure consistency, which has a higher cost. On this hand, providing a simple check could save a lot of work. Since it's used to provide the TSO service, it makes sense to have such a customized change.
|
Do we need to move |
Maybe. But this PR won't do it. |
rleungx
force-pushed
the
tso-rpc
branch
2 times, most recently
from
e3fdecf
to
8c63b02
Compare
Signed-off-by: Ryan Leung <rleungx@gmail.com>
ti-chi-bot
added
the
needs-rebase
|
@rleungx: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
Closed since we are not going to wrap etcd API on the API service side. |
Signed-off-by: Ryan Leung rleungx@gmail.com
What problem does this PR solve?
Issue Number: Ref #5849.
What is changed and how does it work?
This PR implements
Load/SaveTimestampwhich will be used by the TSO service to persist the timestamp. Most of the change in this PR isgo.sum, which is due to the upgrade ofgoogle.golang.org/grpc.Check List
Tests
Release note