[
https://issues.apache.org/jira/browse/KUDU-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905653#comment-15905653
]
Adar Dembo commented on KUDU-1927:
----------------------------------
{noformat}
void MasterServiceImpl::ConnectToMaster(const ConnectToMasterRequestPB* /*req*/,
ConnectToMasterResponsePB* resp,
rpc::RpcContext* rpc) {
CatalogManager::ScopedLeaderSharedLock l(server_->catalog_manager());
if (!l.CheckIsInitializedOrRespond(resp, rpc)) {
return;
}
auto role = server_->catalog_manager()->Role();
resp->set_role(role);
if (l.leader_status().ok()) {
// TODO(PKI): it seems there is some window when 'role' is LEADER but
// in fact we aren't done initializing (and we don't have a CA cert).
// In that case, if we respond with the 'LEADER' role to a client, but
// don't pass back the CA cert, then the client won't be able to trust
// anyone... seems like a potential race bug for clients who connect
// exactly as the leader is changing.
resp->add_ca_cert_der(server_->cert_authority()->ca_cert_der());
// Issue an authentication token for the caller, unless they are
// already using a token to authenticate.
if (rpc->remote_user().authenticated_by() != rpc::RemoteUser::AUTHN_TOKEN) {
SignedTokenPB authn_token;
Status s = server_->token_signer()->GenerateAuthnToken(
rpc->remote_user().username(),
&authn_token);
if (!s.ok()) {
KLOG_EVERY_N_SECS(WARNING, 1)
<< "Unable to generate signed token for " << rpc->requestor_string()
<< ": " << s.ToString();
} else {
// TODO(todd): this might be a good spot for some auditing code?
resp->mutable_authn_token()->Swap(&authn_token);
}
}
}
rpc->RespondSuccess();
}
{noformat}
If !leader_status.ok() but Role() is LEADER, it's indeed a sign that the
consensus state machine has elected this master as leader, but the leader is
still becoming active and setting up in-memory state. In that case, we should
enforce that resp->role() is not set to LEADER (i.e. just overwrite it with
UNKNOWN_ROLE, FOLLOWER, or whatever).
In retrospect, we should have used an "is leader" boolean in
ConnectToMasterResponse instead of exposing the raw Raft role.
> Potential race handling ConnectToMaster RPCs during leader transition
> ---------------------------------------------------------------------
>
> Key: KUDU-1927
> URL: https://issues.apache.org/jira/browse/KUDU-1927
> Project: Kudu
> Issue Type: Bug
> Components: master, security
> Affects Versions: 1.3.0
> Reporter: Todd Lipcon
>
> MasterServiceImpl::ConnectToMaster currently has a TODO that there might be a
> case where a client issues the RPC exactly as a leader is becoming active.
> The worry is that it may return a response indicating LEADER status, but
> without the ability to issue a key.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
