Andrew Wong has posted comments on this change. ( http://gerrit.cloudera.org:8080/14221 )
Change subject: KUDU-2069 p3: add RPC endpoint for maintenance mode ...................................................................... Patch Set 2: (12 comments) http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/master.proto File src/kudu/master/master.proto: http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/master.proto@816 PS2, Line 816: enum StateChange > Do we need to use the same way of assigning the default values for this enu Done http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/master.proto@825 PS2, Line 825: // The tserver UUID on which to apply the state change. > Nit: add an empty line before. Done http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/master.proto@988 PS2, Line 988: AuthorizeSuperUser > nit: Can you mention this requires super user privilege, as it is for admin Done http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/master_service.cc File src/kudu/master/master_service.cc: http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/master_service.cc@98 PS2, Line 98: DEFINE_bool(master_support_maintenance_mode, false, > nit: maybe, add TODO about removing this after all the related patches land Done http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/master_service.cc@132 PS2, Line 132: the end state of the given 'change'. > nit: update the doc -- it returns that into the output parameter, not as re Done http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/master_service.cc@133 PS2, Line 133: ExtractTServerStateFromChangePB > nit: as for naming, what do you think of StateChangeToTServerState() ? Done http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/master_service.cc@202 PS2, Line 202: if (!req->has_change()) { > FWIW, the default value of a protobuf enum is its first possible value. Done, this will be caught in StateChangeToTServerState() http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/ts_state-test.cc File src/kudu/master/ts_state-test.cc: http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/ts_state-test.cc@323 PS2, Line 323: ASSERT_FALSE(s.ok()) > Does it make sense to check for specific status code? Or this isn't any co Done http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/ts_state-test.cc@323 PS2, Line 323: << s.ToString() > nit: if s.ok() is true, not much is going to be reported by s.ToString() by Done http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/ts_state-test.cc@328 PS2, Line 328: NO_FATALS(send_req_check_failed("must contain tserver state change")); > IMHO, these error messages should be defined as string constants somewhere, If it were being used multiple places in production code, I'd agree, or multiple places in tests, I'd agree. But I agree with others that the tests should be decoupled from the implementation. http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/ts_state-test.cc@339 PS2, Line 339: resp > Does it make sense to check for the 'error' in the response even if RPC its Done http://gerrit.cloudera.org:8080/#/c/14221/2/src/kudu/master/ts_state-test.cc@339 PS2, Line 339: ChangeTServerState > Do we need to check the RPC is a no op when transiting tserver to maintenan Done -- To view, visit http://gerrit.cloudera.org:8080/14221 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I9d565bd745507f2511b91a96d2d446240c5406b5 Gerrit-Change-Number: 14221 Gerrit-PatchSet: 2 Gerrit-Owner: Andrew Wong <[email protected]> Gerrit-Reviewer: Adar Dembo <[email protected]> Gerrit-Reviewer: Alexey Serbin <[email protected]> Gerrit-Reviewer: Andrew Wong <[email protected]> Gerrit-Reviewer: Greg Solovyev <[email protected]> Gerrit-Reviewer: Hao Hao <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Comment-Date: Tue, 17 Sep 2019 20:47:12 +0000 Gerrit-HasComments: Yes
