docs: node.store usage updates for celestia-node #1532
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -78,6 +78,33 @@ If you would like to use them anyway, you can | |
|
|
||
| ## Changing the location of your node store | ||
|
|
||
| ### Background | ||
|
|
||
| An [enhancement has been made in v0.14.0+](https://github.com/celestiaorg/celestia-node/pull/3246) | ||
| to automate the detection of the running node, eliminating the need to | ||
| manually specify the `--node.store` flag for each RPC request. | ||
|
|
||
| **Assumptions:** | ||
|
|
||
| - The presence of a lock signifies a running node. | ||
jcstein marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - Networks are ordered as Mainnet, Mocha, Arabica, private, custom. | ||
| - Node types are ordered as bridge, full, and light. | ||
| - Each network has only one running node type. | ||
| - Multiple nodes of the same network and type are prohibited | ||
| (resulting in an `Error: node: store is in use`). | ||
|
|
||
|
Comment on lines
+89
to
+95
There was a problem hiding this comment. Revise the assumptions section for clarity and accuracy. The assumptions listed about the ordering of networks and node types, as well as the prohibition of multiple nodes of the same network and type, are crucial for understanding the operational constraints. Consider expanding on why these assumptions are necessary and how they impact the node's operation to provide clearer guidance to users. |
||
| **Key Points:** | ||
|
|
||
| - Authentication token and other flags maintain their previous behavior | ||
| and take precedence. | ||
| - Address and port details are fetched from the configuration. | ||
| - `skipAuth` allows bypassing authentication for trusted setups and follows | ||
jcstein marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Unix daemon conventions. | ||
| - Non-default node store and cel-key configurations still require specific | ||
| flags in the configuration settings. | ||
|
Comment on lines
+101
to
+104
There was a problem hiding this comment. Ensure the The |
||
|
|
||
| ### Demonstration | ||
|
|
||
| In this section, we'll guide you through starting your node using a | ||
| node store in a different location than you originally started with. | ||
|
|
||
|
|
@@ -113,6 +140,57 @@ To show the keys you should add `--keyring-dir` like this example: | |
| --keyring-dir /home/user/celestia-<node-type>-location/keys/ | ||
| ``` | ||
|
|
||
| ### Examples | ||
|
|
||
| #### Mainnet Beta full and Mocha light | ||
|
|
||
| This example uses a Mainnet Beta full node and a Mocha light node. When | ||
| making the request: | ||
|
|
||
| ```bash | ||
| ❯ celestia blob get 1318129 0x42690c204d39600fddd3 0MFhYKQUi2BU+U1jxPzG7QY2BVV1lb3kiU+zAK7nUiY= | ||
| { | ||
| "result": "RPC client error: sendRequest failed: http status 401 Unauthorized unmarshaling response: EOF" | ||
| } | ||
| ``` | ||
|
|
||
| The request will go to the Mainnet Beta node, and a 401 will show in | ||
| this node's logs. Note that a 401 is expected because this blob was | ||
| posted to Mocha and neither the namespace nor the blob exist on Mainnet. | ||
|
|
||
| #### Mocha full and Arabica light | ||
|
|
||
| This example uses a Mocha full node and an Arabica light node. When | ||
| making the request: | ||
|
|
||
| ```bash | ||
| ❯ celestia blob get 1318129 0x42690c204d39600fddd3 0MFhYKQUi2BU+U1jxPzG7QY2BVV1lb3kiU+zAK7nUiY= | ||
| { | ||
| "result": { | ||
| "namespace": "AAAAAAAAAAAAAAAAAAAAAAAAAEJpDCBNOWAP3dM=", | ||
| "data": "0x676d", | ||
| "share_version": 0, | ||
| "commitment": "0MFhYKQUi2BU+U1jxPzG7QY2BVV1lb3kiU+zAK7nUiY=", | ||
| "index": 23 | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| The request will go to the Mocha full node, and result shown as expected. | ||
|
|
||
| #### Using a custom rpc.config address | ||
|
|
||
| When using a custom RPC config address `0.0.0.1` and port `25231`, | ||
| the CLI accurately routes to the custom address and port, where no | ||
| node is running. It fails as expected: | ||
|
|
||
| ```bash | ||
| ❯ celestia blob get 1318129 0x42690c204d39600fddd3 0MFhYKQUi2BU+U1jxPzG7QY2BVV1lb3kiU+zAK7nUiY= | ||
| { | ||
| "result": "RPC client error: sendRequest failed: Post \"http://0.0.0.1:25231\": dial tcp 0.0.0.1:25231: connect: no route to host" | ||
| } | ||
| ``` | ||
|
Comment on lines
+143
to
+192
There was a problem hiding this comment. Enhance the examples section with more detailed outcomes. The examples provided for different node setups and their expected results are very useful. To enhance understanding, consider adding more context about why certain results are expected, such as the 401 Unauthorized error, and how users can resolve or investigate these issues further. ToolsLanguageTool
|
||
|
|
||
| ## Resetting your config | ||
|
|
||
| If you an encounter an error, it is likely that an old config file is present: | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarification and link addition needed for
node.storeflag change.While the note mentions the change in the usage of the
node.storeflag, it would be beneficial for users if a direct link to the section discussing this change in detail is provided.