-
Notifications
You must be signed in to change notification settings - Fork 148
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
[#80][Part-3] feat: add REST API for decommisson #684
Conversation
# Conflicts: # coordinator/src/main/java/org/apache/uniffle/coordinator/SimpleClusterManager.java
# Conflicts: # common/src/main/java/org/apache/uniffle/common/ServerStatus.java # common/src/main/java/org/apache/uniffle/common/exception/InvalidRequestException.java # common/src/main/java/org/apache/uniffle/common/rpc/StatusCode.java # common/src/test/java/org/apache/uniffle/common/ServerStatusTest.java # coordinator/src/main/java/org/apache/uniffle/coordinator/CoordinatorGrpcService.java # coordinator/src/main/java/org/apache/uniffle/coordinator/CoordinatorServer.java # coordinator/src/main/java/org/apache/uniffle/coordinator/ServerNode.java # coordinator/src/main/java/org/apache/uniffle/coordinator/SimpleClusterManager.java # coordinator/src/test/java/org/apache/uniffle/coordinator/ServerNodeTest.java # integration-test/common/src/test/java/org/apache/uniffle/test/ShuffleServerInternalGrpcTest.java # internal-client/src/main/java/org/apache/uniffle/client/api/ShuffleServerInternalClient.java # internal-client/src/main/java/org/apache/uniffle/client/impl/grpc/ShuffleServerInternalGrpcClient.java # internal-client/src/main/java/org/apache/uniffle/client/request/RssDecommissionRequest.java # internal-client/src/main/java/org/apache/uniffle/client/response/RssDecommissionResponse.java # proto/src/main/proto/Rss.proto # server/src/main/java/org/apache/uniffle/server/ShuffleServer.java # server/src/main/java/org/apache/uniffle/server/ShuffleServerConf.java # server/src/main/java/org/apache/uniffle/server/ShuffleServerInternalGrpcService.java
Codecov Report
@@ Coverage Diff @@
## master #684 +/- ##
============================================
+ Coverage 60.79% 62.99% +2.19%
- Complexity 1839 1858 +19
============================================
Files 221 214 -7
Lines 12655 10774 -1881
Branches 1069 1065 -4
============================================
- Hits 7694 6787 -907
+ Misses 4553 3639 -914
+ Partials 408 348 -60
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
From the example listed in description, I have questions
|
Updated. Now supported. |
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.
The code LGTM generally except one meta question.
common/src/test/java/org/apache/uniffle/common/metrics/TestUtils.java
Outdated
Show resolved
Hide resolved
@@ -179,6 +183,19 @@ private void initialization() throws Exception { | |||
server = coordinatorFactory.getServer(); | |||
} | |||
|
|||
private void registerRESTAPI() throws Exception { | |||
LOG.info("Register REST API"); | |||
jettyServer.addServlet( |
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.
How do you think to struct REST api as follows:
GET /api/v1/servers # list all servers.
GET /api/v1/servers/:id # get the specific server with id.
POST /api/v1/servers/:id/decommission # start decommission of server with id
POST /api/v1/servers/:id/cancelDecommission #...
POST /api/v1/servers/decommission # batch decommission. similar to the current impl
POST /api/v1/servers/cancelDecommission # batch cancel decommission.
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 troublesome to get parameters from path in the current framework. Should we introduce other REST frameworks?
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.
Should we introduce other REST frameworks?
If it's too much trouble, I'm OK with current route path. If it's simple, I prefer the above REST path, which is more idiomatic. It's up to you.
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 will be more and more rest apis in the future. It is still troublesome to add an api under the current framework. So I think we can consider it later. How about introduce Jersey? @advancedxy @jerqi @zuston @kaijchen
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'm not familiar with Jersey. Is it lightweight enough? Is it used widely?
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'm not familiar with Jersey. Is it lightweight enough? Is it used widely?
Yes. Hadoop and Spark use Jersey either.
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'm ok.
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 don't know if Jersey
is lightweight. I hope the restful framework could be modern and lightweight.
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 will be more and more rest apis in the future. It is still troublesome to add an api under the current framework. So I think we can consider it later. How about introduce Jersey? @advancedxy @jerqi @zuston @kaijchen
I'm ok with current status. Let's make the new REST server framework a followup PR. Jersey itself seems a bit complex, but the path annotation https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/user-guide.html#d0e2081 is quite elegant.
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 we can refer to Apache Livy, it use scalatra
. We can use similar Java framework.
https://www.51cto.com/article/311366.html
@smallzhongfeng Could you help me review this pr? |
Done |
coordinator/src/main/java/org/apache/uniffle/coordinator/web/request/DecommissionRequest.java
Outdated
Show resolved
Hide resolved
coordinator/src/main/java/org/apache/uniffle/coordinator/web/request/DecommissionRequest.java
Outdated
Show resolved
Hide resolved
coordinator/src/main/java/org/apache/uniffle/coordinator/web/servlet/BaseServlet.java
Outdated
Show resolved
Hide resolved
coordinator/src/main/java/org/apache/uniffle/coordinator/web/servlet/BaseServlet.java
Show resolved
Hide resolved
The GA failure cause by CoordinatorMetricsTest, could you rebase the latest code and trigger test again ? |
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.
LGTM. 👍
Thanks @xianjingfeng for the work, and thanks everyone reviewing. |
### What changes were proposed in this pull request? Add REST API for decommisson ### Why are the changes needed? Support shuffle server decommission. It is a part of apache#80 ### Does this PR introduce _any_ user-facing change? Env: * Server IP: 127.0.0.1 * HTTP port: 19998 * RPC port: 19999 Decommission example: ```shell curl -XPOST -H "Content-type:application/json" "http://127.0.0.1:19998/api/server/decommission" -d '{"serverIds:": ["127.0.0.1:19999"]}' ``` Cancel decommission example: ```shell curl -XPOST -H "Content-type:application/json" "http://127.0.0.1:19998/api/server/cancelDecommission" -d '{"serverIds:": ["127.0.0.1:19999"]}' ``` Get server list: ```shell # path: /api/server/nodes[?id={serverId}][?status={serverStatus}] curl "http://127.0.0.1:19998/api/server/nodes?status=DECOMMISSIONING" curl "http://127.0.0.1:19998/api/server/nodes?status=ACTIVE" ``` ### How was this patch tested? UT
### What changes were proposed in this pull request? Add REST API for decommisson ### Why are the changes needed? Support shuffle server decommission. It is a part of apache#80 ### Does this PR introduce _any_ user-facing change? Env: * Server IP: 127.0.0.1 * HTTP port: 19998 * RPC port: 19999 Decommission example: ```shell curl -XPOST -H "Content-type:application/json" "http://127.0.0.1:19998/api/server/decommission" -d '{"serverIds:": ["127.0.0.1:19999"]}' ``` Cancel decommission example: ```shell curl -XPOST -H "Content-type:application/json" "http://127.0.0.1:19998/api/server/cancelDecommission" -d '{"serverIds:": ["127.0.0.1:19999"]}' ``` Get server list: ```shell # path: /api/server/nodes[?id={serverId}][?status={serverStatus}] curl "http://127.0.0.1:19998/api/server/nodes?status=DECOMMISSIONING" curl "http://127.0.0.1:19998/api/server/nodes?status=ACTIVE" ``` ### How was this patch tested? UT
What changes were proposed in this pull request?
Add REST API for decommisson
Why are the changes needed?
Support shuffle server decommission. It is a part of #80
Does this PR introduce any user-facing change?
Env:
Decommission example:
Cancel decommission example:
Get server list:
How was this patch tested?
UT