You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment the node can be run in the following modes:
non-smeshing: the node still creates an identity if none exists already but doesn't initialize post (--smeshing-start=false)
This mode of operation can be used by users to run a node without generating rewards by not initializing post and not participating in consensus
supervised-smeshing: the node creates and manages the post data.
after mainnet launch this was the main mode of operation until other modes were added
remote-/multi-smeshing: the node only manages identities but post is managed with postcli and post-service
this allows users to have multiple identities without having to run multiple nodes
Description
Remove the need for an identity in non-smeshing nodes
It should be checked if in this operating mode generating an identity is even necessary. On a quick check it appears that components that are called with Register(signer) would also work as expected if Register is never called.
Remove supervised-smeshing mode
There are some issues reported by users surrounding initialization in this smeshing mode - specifically that starting the node with incorrect smeshing options could lead to the node deleting PoST data without re-confirmation by the user. This mode should be replaced with a remote setup in a backwards compatible way that is as simple to operate for new users as supervised-smeshing is.
Smapp should start the node in a remote-/multi-smeshing configuration while managing the PoST data with postcli. when the PoST data has been fully initialized it should start a post-service that is configured to connect to the node on local host. This way users can manage their PoST data via smapp (which calls postcli in the background to make changes) and smapp doesn't need to tinker with node configuration and restarts of the node to make changes (post service still needs to be restarted though).
Implementation hints
Node
Without the need for initialization in the node the Post setup manager as well as some GRPC endpoints could be removed. Probably even start&stop smeshing via GRPC isn't needed any more when the node regularly reloads identities from disk. Without the need of supervision of PoST we could also remove the PoST supervisor service and the post-service binary from the node docker images. This way a user could start a non-smeshing node, init an identity, add its key to the node, the node loads that identity from disk and waits for a post service to connect.
With the Register(signer) interface of all services implement now these changes should be relatively easy to do
System tests
There are already system tests running remote-/multi-smeshing setups. There an init container is used to generate the post data for the post-service that connects to the node. The same approach can be used for "supervised" nodes.
Furthermore running 2 processes in a docker container is costly in terms of performance and makes things more difficult than it needs to be. We should consider to stop supporting this setup at all and run system tests only in remote-/multi-smeshing mode. If we do this has to be communicated clearly to the community. It is possible that some users run a containerized setup with supervised smeshing still and have not yet migrated to the remote-/multi-smeshing configuration.
Additionally we should add multi-smeshing nodes in our system tests. At the moment only remote and supervised smeshers are being used. But this might fit better as part of #6494
The text was updated successfully, but these errors were encountered:
Motivation
At the moment the node can be run in the following modes:
--smeshing-start=false
)postcli
andpost-service
Description
Remove the need for an identity in non-smeshing nodes
It should be checked if in this operating mode generating an identity is even necessary. On a quick check it appears that components that are called with
Register(signer)
would also work as expected ifRegister
is never called.Remove supervised-smeshing mode
There are some issues reported by users surrounding initialization in this smeshing mode - specifically that starting the node with incorrect smeshing options could lead to the node deleting PoST data without re-confirmation by the user. This mode should be replaced with a remote setup in a backwards compatible way that is as simple to operate for new users as supervised-smeshing is.
Smapp should start the node in a remote-/multi-smeshing configuration while managing the PoST data with
postcli
. when the PoST data has been fully initialized it should start a post-service that is configured to connect to the node on local host. This way users can manage their PoST data via smapp (which callspostcli
in the background to make changes) and smapp doesn't need to tinker with node configuration and restarts of the node to make changes (post service still needs to be restarted though).Implementation hints
Node
Without the need for initialization in the node the Post setup manager as well as some GRPC endpoints could be removed. Probably even start&stop smeshing via GRPC isn't needed any more when the node regularly reloads identities from disk. Without the need of supervision of PoST we could also remove the PoST supervisor service and the post-service binary from the node docker images. This way a user could start a non-smeshing node, init an identity, add its key to the node, the node loads that identity from disk and waits for a post service to connect.
With the
Register(signer)
interface of all services implement now these changes should be relatively easy to doSystem tests
There are already system tests running remote-/multi-smeshing setups. There an init container is used to generate the post data for the post-service that connects to the node. The same approach can be used for "supervised" nodes.
Furthermore running 2 processes in a docker container is costly in terms of performance and makes things more difficult than it needs to be. We should consider to stop supporting this setup at all and run system tests only in remote-/multi-smeshing mode. If we do this has to be communicated clearly to the community. It is possible that some users run a containerized setup with supervised smeshing still and have not yet migrated to the remote-/multi-smeshing configuration.
Additionally we should add multi-smeshing nodes in our system tests. At the moment only remote and supervised smeshers are being used. But this might fit better as part of #6494
The text was updated successfully, but these errors were encountered: