[−][src]Crate exonum_supervisor
Supervisor is an Exonum service capable of the following activities:
- Service artifact deployment;
- Service instances creation;
- Changing consensus configuration;
- Changing service instances configuration.
More information on the artifact/service lifecycle can be found in the documentation for the Exonum runtime module.
Supervisor service has two different operating modes: a "simple" mode and a "decentralized" mode. The difference between modes is in the decision making approach:
- Within the decentralized mode, to deploy a service or apply a new configuration, no less than (2/3)+1 validators should reach a consensus;
- Within the simple mode, any decision is executed after a single validator approval.
The simple mode can be useful if one network administrator manages all the validator nodes
or for testing purposes (e.g., to test service configuration with TestKit).
For a network with a low node confidence, consider using the decentralized mode.
Interaction
The intended way to interact with supervisor is the REST API. To be precise, requests should
be sent to the one of the following endpoints: deploy-artifact, propose-config or
confirm-config. Once received, supervisor will convert the request into appropriate
transaction, sign it with the validator keys and broadcast for the rest of the network.
Key point here is that user should not send transactions to the supervisor by himself.
An expected format of requests for those endpoints is a serialized Protobuf message.
To deploy an artifact, one (within the "simple" mode) or majority (within the "decentralized" mode)
of the nodes should receive a DeployRequest message through API.
To request a config change, one node should receive a ConfigPropose message through API.
For the "simple" mode no more actions are required. For the "decentralized" mode the majority of the nodes
should also receive ConfigVote messages with a hash of the proposed configuration.
The proposal initiator that receives the original ConfigPropose message must not vote for the configuration.
This node votes for the configuration propose automatically.
The operation of starting a service is treated similarly to a configuration change and follows the same rules.
Modules
| mode | Module with available running modes for Supervisor. |
Structs
| ConfigProposalWithHash | Pending config change proposal entry |
| ConfigPropose | Request for the configuration change |
| ConfigVote | Confirmation vote for the configuration change |
| ConfigureCall | A helper struct for invoking the |
| DeployConfirmation | Request for the artifact deployment. |
| DeployRequest | Request for the artifact deployment. |
| Schema | Service information schema. |
| ServiceConfig | Configuration parameters of the certain service instance. |
| StartService | Request for the artifact deployment. |
| Supervisor | Supervisor service implementation. |
Enums
| ConfigChange | Atomic configuration change. |
| Error | Common errors emitted by transactions during execution. |
Constants
| CONFIGURE_INTERFACE_NAME | Fully qualified name of the 'Configure` interface. |
Traits
| Configure | Describes a procedure for updating the configuration of a service instance. |
| SupervisorInterface | Supervisor service transactions. |
Functions
| supervisor_name | Returns the |
Type Definitions
| DecentralizedSupervisor | Decentralized supervisor. |
| SimpleSupervisor | Simple supervisor. |