sawtooth-rfcs
sawtooth-rfcs copied to clipboard
hyperledger-archives
Add new peers without restarting a node
Proposes an extension of validator client messaging to add peers to a running node without restarting it.
Signed-off-by: Yevhenii Babichenko [email protected]
I think this would be a useful addition to the administrative APIs. Main thing to work out are security cosiderations.
Just uploaded an update. Here is what is changed:
- Extended the range of error codes for adding peers.
- Added the description for peers removal.
- Now requests for adding peers are submitted one by one instead of doing that in batches. The rationale behind that is fairly simple. Now this RFC support error codes that are returned after the connection is finished or failed. Because of that we need control over each separate connection and they may fail with different errors.
- Added the description of the permissioning model. This is very basic and I doubt if it should be generalized somehow (added that to the "Unresloved questions" section).
I like this proposal overall.
I wonder if this truly belongs in the Client* message namespace, or whether we should have an administrative set of messages. This is similar to the question of whether it should be exposed in the REST API, but more fundamentally whether it should be able to be bound to a different port.
I am not sure if we should define a separate namespace here — this falls beyond the scope of this proposal. I followed the simple logic here: if something does not belong to TPs or consensus engine, this should be in the Client* namespace.
Do you mean by "to be bound to a different port" that those messages should be on a different port than component?
Should the authorization for this feature occur during the connection conversation (see authorization.proto)? I think it may be appropriate to add ADMIN to "RoleType" and create an Admin* message namespace in addition to Client*, etc.
Should the authorization for this feature occur during the connection conversation (see authorization.proto)?
It may be difficult to implement the authorization in the component endpoint. Should we extend the component endpoint, use the network endpoint (it already has the authorization implemented) or create a separate admin endpoint?
I think it may be appropriate to add ADMIN to "RoleType" and create an Admin* message namespace in addition to Client*, etc.
Agree on that.
Should the authorization for this feature occur during the connection conversation (see authorization.proto)?
It may be difficult to implement the authorization in the component endpoint. Should we extend the component endpoint, use the network endpoint (it already has the authorization implemented) or create a separate admin endpoint?
I think an admin endpoint would be the most secure. This would facilitate firewall rules to restrict traffic. The downside is it adds one more element to a node setup. We used to get a lot of support questions stemming from configuring the existing endpoints. That said, I don't think this will add much complexity. A loopback default wouldn't need to be modified. A simple setup would then have the administrator logging into the validator host to issue these commands and the respective private key could reside on that validator host adding no other key management burden.
Is that OK if I reopen this pull request from another repository?
@agunde406 The problem is I no longer have access to this fork but still want to finish this RFC.
@eugene-babichenko Ah okay. In that case, yes it is okay to resubmit the RFC from a new fork. Please do not change commit history and link this PR in the new one.
@agunde406 Here is the new pull request https://github.com/hyperledger/sawtooth-rfcs/pull/44