Open poszu opened 1 month ago
@poszu Regarding #2. While I agree that it's more flexible to use postcli for POS initialization, I can't agree with that statement. I know that a lot of people using go-sm to init POS. Yes, it makes sense to remove that code from go-sm. Can go-sm call postcli as external function?
Looks good so far, what I'm missing:
postcli
as part of the official go-spacemesh
docker image (and release archive) and update the documentation on how to use it (natively and with docker)go-spacemesh
with postcli
or the existing postcli
docker image) for post initialization for nodes with supervised smeshing (remote smeshing nodes already use postcli
docker image for init).@Stizerg: the primary reason we remove init from the node is because
a) the node right now requires OpenCL to be installed on your system only because of it - if we remove init from the node it can be installed and operated on a system without OpenCL
b) initialization with the node is less flexible and more easy to make mistakes with (i.e. deleting files) than when using postcli
. This also isn't easy to be fixed without breaking other things in the node.
c) with init removed from the node, initialization and sync can be controlled individually more easily.
It should also be easier to build a nice UI around postcli
for initialization than around go-spacemesh
.
Status quo
The POS data initialization is built into the go-spacemesh node. It complicates the code but is not very useful. Users could be divided into two main groups:
Proposal
The proposal is to remove initialization implementation from go-spacemesh.
Steps
Notes
It would be best to first refactor smapp to use postcli and run it in production for a while. In case something goes wrong, it would be easier to rollback. After the new initialization way is proven to work nicely, we can proceed and remove init from go-spacemesh.