Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace Postsetup Manager with postcli in supervised smeshing #6546

Open
fasmat opened this issue Dec 16, 2024 · 0 comments
Open

Replace Postsetup Manager with postcli in supervised smeshing #6546

fasmat opened this issue Dec 16, 2024 · 0 comments
Assignees

Comments

@fasmat
Copy link
Member

fasmat commented Dec 16, 2024

Motivation

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant