From f7cdbc9f4cd25a1dae19276d64f6f327e547b1ae Mon Sep 17 00:00:00 2001 From: Richard Davison Date: Mon, 31 Oct 2022 03:45:09 -0400 Subject: [PATCH 01/13] Docs: daemons --- docs/CHANGES.rst | 4 ++-- docs/Makefile | 12 ++++++------ docs/alpha/cli-commands.rst | 4 ++-- docs/alpha/liquidity_baking.rst | 4 ++-- docs/developer/python_testing_framework.rst | 4 ++-- docs/introduction/howtoget.rst | 2 +- docs/introduction/howtorun.rst | 6 +++--- docs/introduction/howtouse.rst | 10 +++++----- docs/kathmandu/cli-commands.rst | 4 ++-- docs/kathmandu/liquidity_baking.rst | 4 ++-- docs/lima/cli-commands.rst | 4 ++-- docs/lima/liquidity_baking.rst | 4 ++-- docs/user/logging.rst | 2 +- docs/user/sandbox.rst | 2 +- 14 files changed, 33 insertions(+), 33 deletions(-) diff --git a/docs/CHANGES.rst b/docs/CHANGES.rst index 4821a7915e78..1ea0fb45e177 100644 --- a/docs/CHANGES.rst +++ b/docs/CHANGES.rst @@ -494,9 +494,9 @@ Baker ----- The following breaking changes affect the Octez v13.0~rc1 baker daemon -for the Jakarta 2 protocol ``tezos-baker-013-PtJakart``, but **not** the +for the Jakarta 2 protocol ``octez-baker-013-PtJakart``, but **not** the corresponding one for the the Ithaca 2 protocol, -``tezos-baker-012-Psithaca``. +``octez-baker-012-Psithaca``. - **Breaking change**: The ``--liquidity-baking-escape-vote`` command-line option has been renamed diff --git a/docs/Makefile b/docs/Makefile index 65f5e091213d..722210967c1b 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -43,15 +43,15 @@ full: odoc # Build the manuals for a given protocol %/tezos-client.html: @../tezos-client -protocol $($(@D)_long) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@ -%/tezos-baker.html: - @../tezos-baker-$($(@D)_short) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@ -%/tezos-accuser.html: - @../tezos-accuser-$($(@D)_short) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@ +%/octez-baker.html: + @../octez-baker-$($(@D)_short) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@ +%/octez-accuser.html: + @../octez-accuser-$($(@D)_short) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@ manuals: \ $(PROTOCOLS:%=%/tezos-client.html) \ - $(PROTOCOLS:%=%/tezos-baker.html) \ - $(PROTOCOLS:%=%/tezos-accuser.html) + $(PROTOCOLS:%=%/octez-baker.html) \ + $(PROTOCOLS:%=%/octez-accuser.html) # generic @../tezos-admin-client man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/tezos-admin-client.html @../tezos-signer man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/tezos-signer.html diff --git a/docs/alpha/cli-commands.rst b/docs/alpha/cli-commands.rst index 803e866ca0dc..4846a1e15ac1 100644 --- a/docs/alpha/cli-commands.rst +++ b/docs/alpha/cli-commands.rst @@ -29,7 +29,7 @@ Baker manual ============ .. raw:: html - :file: tezos-baker.html + :file: octez-baker.html .. _accuser_manual_alpha: @@ -38,4 +38,4 @@ Accuser manual ============== .. raw:: html - :file: tezos-accuser.html + :file: octez-accuser.html diff --git a/docs/alpha/liquidity_baking.rst b/docs/alpha/liquidity_baking.rst index 16784faf7a77..19f4bd704f37 100644 --- a/docs/alpha/liquidity_baking.rst +++ b/docs/alpha/liquidity_baking.rst @@ -62,13 +62,13 @@ non-abstaining blocks, about 1386 blocks if everyone signals, 1963 blocks if 80% do, 3583 blocks if 60% do etc. Recall for comparison that assuming two blocks per minute there are 2880 blocks per day. -When producing blocks using Octez baking daemon ``tezos-baker``, there +When producing blocks using Octez baking daemon ``octez-baker``, there are two command-line options affecting toggle vote. The ``--liquidity-baking-toggle-vote `` option sets a static value to be used in each block. Note that this option must be placed **after** ``run`` on the command-line. Moreover, the path of a JSON file can be given to the ``--votefile `` option -e.g. ``tezos-baker- run with local node +e.g. ``octez-baker- run with local node ~/.tezos-node alice --liquidity-baking-toggle-vote on --votefile "per_block_votes.json"``, or placed in a default location: ``per_block_votes.json`` in the current working directory. The content diff --git a/docs/developer/python_testing_framework.rst b/docs/developer/python_testing_framework.rst index 6aac9e903c0a..c577a7d54511 100644 --- a/docs/developer/python_testing_framework.rst +++ b/docs/developer/python_testing_framework.rst @@ -495,8 +495,8 @@ Testing on a production branch (``zeronet``, ``mainnet``,...) On ``master``, protocol Alpha is named ``ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK``, and daemons binary -name are suffixed with ``alpha`` (``tezos-baker-alpha``, -``tezos-accuser-alpha``...). However, on *production* branches, an actual +name are suffixed with ``alpha`` (``octez-baker-alpha``, +``octez-accuser-alpha``...). However, on *production* branches, an actual hash of the protocol is used, and a shortened string is used to specify daemons. diff --git a/docs/introduction/howtoget.rst b/docs/introduction/howtoget.rst index 8fc1b4cff45f..bae01a21856c 100644 --- a/docs/introduction/howtoget.rst +++ b/docs/introduction/howtoget.rst @@ -337,7 +337,7 @@ Now, install all the binaries by: :end-before: [test executables] You can be more specific and only ``opam install tezos-node``, ``opam -install tezos-baker-alpha``, ... In that case, it is enough to install +install octez-baker-alpha``, ... In that case, it is enough to install the system dependencies of this package only by running ``opam depext tezos-node`` for example instead of ``opam depext tezos``. diff --git a/docs/introduction/howtorun.rst b/docs/introduction/howtorun.rst index d22c1923e8fe..52ab6e081de9 100644 --- a/docs/introduction/howtorun.rst +++ b/docs/introduction/howtorun.rst @@ -169,7 +169,7 @@ accounts have the necessary rights. Let's launch the daemon pointing to the standard node directory and baking for user *bob*:: - tezos-baker-alpha run with local node ~/.tezos-node bob --liquidity-baking-toggle-vote pass + octez-baker-alpha run with local node ~/.tezos-node bob --liquidity-baking-toggle-vote pass Note that the baker needs direct access to the node data directory for performance reasons (to reduce the number of RPC calls to the node). @@ -187,7 +187,7 @@ Note that ``--liquidity-baking-toggle-vote`` must be placed .. note:: In protocols before Ithaca, a separate daemon, the endorser, is responsible for emitting endorsements. - In these protocols, one needs to run the daemon ``tezos-endorser-NNN-*`` to endorse. + In these protocols, one needs to run the daemon ``octez-endorser-NNN-*`` to endorse. Accuser ~~~~~~~ @@ -205,7 +205,7 @@ cause the offender to be :ref:`slashed`, that is, to lose part of its :: - tezos-accuser-alpha run + octez-accuser-alpha run Docker diff --git a/docs/introduction/howtouse.rst b/docs/introduction/howtouse.rst index 4d4dfd2b3b49..3ea6287b9133 100644 --- a/docs/introduction/howtouse.rst +++ b/docs/introduction/howtouse.rst @@ -18,8 +18,8 @@ After a successful compilation, you should have the following binaries: - ``tezos-node``: the tezos daemon itself (see `Node`_); - ``tezos-client``: a command-line client and basic wallet (see `Client`_); - ``tezos-admin-client``: administration tool for the node (see :ref:`tezos-admin-client`); -- ``tezos-{baker,accuser}-*``: daemons to bake and accuse on the Tezos network (see :doc:`howtorun`); - note that prior to v12 of Octez, there was also an endorser daemon ``tezos-endorser-*``; +- ``octez-{baker,accuser}-*``: daemons to bake and accuse on the Tezos network (see :doc:`howtorun`); + note that prior to v12 of Octez, there was also an endorser daemon ``octez-endorser-*``; - ``tezos-validator``: a daemon for validating and applying operations in blocks (see `Validator`_) - ``tezos-signer``: a client to remotely sign operations or blocks (see :ref:`signer`); @@ -30,8 +30,8 @@ After a successful compilation, you should have the following binaries: The daemons other than the node are suffixed with the name of the protocol they are bound to, and up to some version, also by its number. -For instance, ``tezos-baker-014-PtKathma`` is the baker -for the Kathmandu protocol, and ``tezos-baker-alpha`` is the baker +For instance, ``octez-baker-014-PtKathma`` is the baker +for the Kathmandu protocol, and ``octez-baker-alpha`` is the baker of the development protocol. The ``tezos-node`` daemon is not suffixed by any protocol name, because it is independent of the economic protocol. See also the `Node's Protocol`_ section below. @@ -110,7 +110,7 @@ network. Other than passively observing the network, your node can also inject its own new operations when instructed by the ``tezos-client`` and even -send new blocks when guided by the ``tezos-baker-*``. +send new blocks when guided by the ``octez-baker-*``. The node has also a view of the multiple chains that may exist concurrently and selects the best one based on its fitness (see :doc:`../active/consensus`). diff --git a/docs/kathmandu/cli-commands.rst b/docs/kathmandu/cli-commands.rst index 0eaba7aebaa7..94c81d59affc 100644 --- a/docs/kathmandu/cli-commands.rst +++ b/docs/kathmandu/cli-commands.rst @@ -31,7 +31,7 @@ Baker manual ============ .. raw:: html - :file: tezos-baker.html + :file: octez-baker.html .. _accuser_manual: @@ -41,4 +41,4 @@ Accuser manual ============== .. raw:: html - :file: tezos-accuser.html + :file: octez-accuser.html diff --git a/docs/kathmandu/liquidity_baking.rst b/docs/kathmandu/liquidity_baking.rst index 63c6270bdc4d..f7cfa46098bf 100644 --- a/docs/kathmandu/liquidity_baking.rst +++ b/docs/kathmandu/liquidity_baking.rst @@ -68,13 +68,13 @@ non-abstaining blocks, about 1386 blocks if everyone signals, 1963 blocks if 80% do, 3583 blocks if 60% do etc. Recall for comparison that assuming two blocks per minute there are 2880 blocks per day. -When producing blocks using Octez baking daemon ``tezos-baker``, there +When producing blocks using Octez baking daemon ``octez-baker``, there are two command-line options affecting toggle vote. The ``--liquidity-baking-toggle-vote `` option sets a static value to be used in each block. Note that this option must be placed **after** ``run`` on the command-line. Moreover, the path of a JSON file can be given to the ``--votefile `` option -e.g. ``tezos-baker- run with local node +e.g. ``octez-baker- run with local node ~/.tezos-node alice --liquidity-baking-toggle-vote on --votefile "per_block_votes.json"``, or placed in a default location: ``per_block_votes.json`` in the current working directory. The content diff --git a/docs/lima/cli-commands.rst b/docs/lima/cli-commands.rst index b1c68ec2f353..e86875308b1e 100644 --- a/docs/lima/cli-commands.rst +++ b/docs/lima/cli-commands.rst @@ -29,7 +29,7 @@ Baker manual ============ .. raw:: html - :file: tezos-baker.html + :file: octez-baker.html .. _accuser_manual_lima: @@ -38,4 +38,4 @@ Accuser manual ============== .. raw:: html - :file: tezos-accuser.html + :file: octez-accuser.html diff --git a/docs/lima/liquidity_baking.rst b/docs/lima/liquidity_baking.rst index 980530eea74d..17c8a588cbff 100644 --- a/docs/lima/liquidity_baking.rst +++ b/docs/lima/liquidity_baking.rst @@ -62,13 +62,13 @@ non-abstaining blocks, about 1386 blocks if everyone signals, 1963 blocks if 80% do, 3583 blocks if 60% do etc. Recall for comparison that assuming two blocks per minute there are 2880 blocks per day. -When producing blocks using Octez baking daemon ``tezos-baker``, there +When producing blocks using Octez baking daemon ``octez-baker``, there are two command-line options affecting toggle vote. The ``--liquidity-baking-toggle-vote `` option sets a static value to be used in each block. Note that this option must be placed **after** ``run`` on the command-line. Moreover, the path of a JSON file can be given to the ``--votefile `` option -e.g. ``tezos-baker- run with local node +e.g. ``octez-baker- run with local node ~/.tezos-node alice --liquidity-baking-toggle-vote on --votefile "per_block_votes.json"``, or placed in a default location: ``per_block_votes.json`` in the current working directory. The content diff --git a/docs/user/logging.rst b/docs/user/logging.rst index ef97b14f1e9f..7d522ee29498 100644 --- a/docs/user/logging.rst +++ b/docs/user/logging.rst @@ -280,7 +280,7 @@ events) this call adds a sink to suddenly start pretty-printing all Client and Baking Daemons ------------------------- -For now, ``tezos-client``, ``tezos-{baker,accuser}-*``, etc. +For now, ``tezos-client``, ``octez-{baker,accuser}-*``, etc. can only be configured using the environment variables. There is one common option ``--log-requests`` which can be used to trace diff --git a/docs/user/sandbox.rst b/docs/user/sandbox.rst index 211649f73a94..d0426377c7fc 100644 --- a/docs/user/sandbox.rst +++ b/docs/user/sandbox.rst @@ -108,7 +108,7 @@ we can do so with the following command: If the previous transaction is valid, the operation is included in the chain and the transfer terminates returning the usual receipt. Note that the ``bake for`` command of the client is exclusively for -testing purposes, all baking should be done using the ``tezos-baker`` +testing purposes, all baking should be done using the ``octez-baker`` binary. -- GitLab From 6791c675d6d0fa1683db4dee68b700ec15f98048 Mon Sep 17 00:00:00 2001 From: Richard Davison Date: Fri, 9 Sep 2022 16:05:21 -0400 Subject: [PATCH 02/13] Docs: octez-node --- docs/CHANGES.rst | 48 ++++++++++++------------- docs/Makefile | 2 +- docs/api/rpc-openapi.json | 2 +- docs/developer/clic.rst | 2 +- docs/developer/contributing.rst | 2 +- docs/developer/openmetrics.rst | 2 +- docs/developer/profiling.rst | 10 +++--- docs/developer/proposal_testing.rst | 32 ++++++++--------- docs/developer/rpc.rst | 2 +- docs/developer/testing.rst | 4 +-- docs/developer/time_measurement_ppx.rst | 2 +- docs/introduction/howtoget.rst | 6 ++-- docs/introduction/howtouse.rst | 22 ++++++------ docs/shell/cli-commands.rst | 2 +- docs/user/history_modes.rst | 8 ++--- docs/user/logging.rst | 4 +-- docs/user/multinetwork.rst | 10 +++--- docs/user/node-config.sh | 8 ++--- docs/user/node-configuration.rst | 40 ++++++++++----------- docs/user/proxy-server.rst | 8 ++--- docs/user/sandbox.rst | 2 +- docs/user/snapshots.rst | 10 +++--- 22 files changed, 114 insertions(+), 114 deletions(-) diff --git a/docs/CHANGES.rst b/docs/CHANGES.rst index 1ea0fb45e177..492e3352fdd1 100644 --- a/docs/CHANGES.rst +++ b/docs/CHANGES.rst @@ -275,7 +275,7 @@ Node - Added a store metric to expose the number of blocks considered as invalid. -- Fixed the ``tezos-node config reset`` command which did not actually reset +- Fixed the ``octez-node config reset`` command which did not actually reset the configuration file to its default values. - Added metrics to observe the bootstrapped and synchronisation status. @@ -310,7 +310,7 @@ Node upgraded. To this end, a new storage version was introduced: 1.0 (previously 0.8). Backward compatibility is preserved: upgrading from 0.6, 0.7 (Octez 12.x) or 0.8 (Octez 13.0) is done through the - ``tezos-node upgrade storage`` command. This upgrade is + ``octez-node upgrade storage`` command. This upgrade is instantaneous. However, be careful that there is no forward compatibility: previous versions of Octez will refuse to run on an upgraded data directory. @@ -416,10 +416,10 @@ Node must be used for RPC requests to the node. The value can be ``json``, ``binary`` or ``any``. By default, the value is set to ``any``. -- Added an option ``--metrics-addr :`` to ``tezos-node`` to +- Added an option ``--metrics-addr :`` to ``octez-node`` to expose some metrics using the Prometheus format. -- Added command ``tezos-node storage head-commmit`` which prints the commit hash +- Added command ``octez-node storage head-commmit`` which prints the commit hash of the current context head. - Added a history mode check when importing a snapshot to ensure the consistency between the @@ -461,7 +461,7 @@ Node limit, and therefore not stored. The re-computed metadata are not stored on disk after this call, but rather just returned by the RPC call. -- Added ``--progress-display-mode`` option to the ``tezos-node`` commands +- Added ``--progress-display-mode`` option to the ``octez-node`` commands that display progress animation. This option allows to redirect progress animation to non-TTY file descriptors. @@ -654,7 +654,7 @@ Version 12.0 Node ---- -- The tezos-node configuration file parameter +- The octez-node configuration file parameter ``shell.prevalidator.limits.max_refused_operations`` is now deprecated and may be removed starting from version 13.0. @@ -873,7 +873,7 @@ Node rejected because of this limitation are solely delayed to a future block. - Removed support for store versions 0.0.4 (used by Octez 9.7) or below. - It is no longer possible to run ``tezos-node upgrade storage`` to upgrade + It is no longer possible to run ``octez-node upgrade storage`` to upgrade from those older versions. It is also no longer possible to import snapshots that were exported using this version. @@ -1166,7 +1166,7 @@ Client - Fix gas simulation for operation batches for Granada, Hangzhou and Alpha - Added timestamp display of the snapshot's block target when running - the ``tezos-node snapshot info`` command. + the ``octez-node snapshot info`` command. Baker / Endorser / Accuser -------------------------- @@ -1230,7 +1230,7 @@ Docker Images ------------- - The ``--force-history-mode-switch`` option is now available for - ``tezos-node`` entrypoint. It allows the user to switch the history + ``octez-node`` entrypoint. It allows the user to switch the history mode of the node's storage. Version 10.2 @@ -1268,13 +1268,13 @@ Node If you were previously using Octez 10.0~rc1 or 10.0~rc2, you were using store version 0.0.5. If you were previously using Octez 9.x, you were using store version 0.0.4. In both cases, use command - ``tezos-node upgrade storage`` to upgrade to 0.0.6. + ``octez-node upgrade storage`` to upgrade to 0.0.6. - Added an upgrade procedure to upgrade from ``v0.0.5`` to ``v0.0.6``. The - procedure is implemented through the ``tezos-node upgrade storage`` + procedure is implemented through the ``octez-node upgrade storage`` command. -- Added an ``integrity-check-index`` subcommand to ``tezos-node +- Added an ``integrity-check-index`` subcommand to ``octez-node storage``, which can be used to check for corruptions (missing entries) in the index of the store. This command also accepts an optional flag ``--auto-repair`` to fix those specific corruptions @@ -1341,7 +1341,7 @@ Node - Added an upgrade procedure to upgrade from the previous store to the new one. The procedure is implemented through the - ``tezos-node upgrade storage`` command. This command is + ``octez-node upgrade storage`` command. This command is non-destructive: the previous store is preserved at ``/lmdb_store_to_be_removed`` and needs to be manually removed when the user made sure the upgrade process went well. @@ -1359,12 +1359,12 @@ Node suitable for IPFS sharing - The argument ``[output_file]`` in - ``tezos-node export snapshot [output_file]`` becomes optional and + ``octez-node export snapshot [output_file]`` becomes optional and defaults to a file whose name follows this pattern ``--.`` - Improved the metadata of snapshots which can be displayed using - ``tezos-node snapshot info`` - - The ``tezos-node snapshot import`` command is retro-compatible + ``octez-node snapshot info`` + - The ``octez-node snapshot import`` command is retro-compatible with the previous snapshot format (v1) but legacy snapshots cannot be exported anymore @@ -1378,7 +1378,7 @@ Node two modes were maintaining a window of ```` cycles of metadata (``5`` on mainnet). These modes may now be configured to keep a larger window of metadata. E.g. - ``tezos-node run --history-mode full+2`` will maintain 2 extra cycles + ``octez-node run --history-mode full+2`` will maintain 2 extra cycles of metadata, in addition to the network’s preserved cycles. This may become useful for users that want to keep more data from the past: for instance, to compute rewards payouts. The default number of extra @@ -1955,7 +1955,7 @@ Node significance are detailed in `the user documentation `__. -- Command ``tezos-node --version`` now exits with exit code 0 instead +- Command ``octez-node --version`` now exits with exit code 0 instead of 1. - Fixed the synchronisation threshold which was wrongly capped with an @@ -2031,8 +2031,8 @@ Node - Fixed an issue which prevented using ports higher than 32767 in the client configuration file. -- The ``tezos-node run`` command now automatically generates an - identity file as if you had run ``tezos-node identity generate`` if +- The ``octez-node run`` command now automatically generates an + identity file as if you had run ``octez-node identity generate`` if its data directory contains no identity file. - Improved various log messages and errors. @@ -2084,7 +2084,7 @@ Node - Improved the performance of the progress indicator when importing snapshots. -- Improved performance of ``tezos-node snapshot export``. +- Improved performance of ``octez-node snapshot export``. - Fixed the node which sent too many “get current branch” messages to its peers on testchain activation. @@ -2295,14 +2295,14 @@ Multinetwork - Node and client now come with all current and past protocols that are still in use on Mainnet or some active test networks. -- Added option ``--network`` to ``tezos-node config init`` to select +- Added option ``--network`` to ``octez-node config init`` to select which network to connect to from a list of built-in networks (e.g. ``carthagenet``). If you do not run ``config init`` or run it without the ``--network`` option, the node will use the default network (Mainnet). -- Added option ``--network`` to ``tezos-node run`` and - ``tezos-node snapshot import`` which causes the node to check that it +- Added option ``--network`` to ``octez-node run`` and + ``octez-node snapshot import`` which causes the node to check that it is configured to use the given network. - Added ``network`` configuration field to select which network to diff --git a/docs/Makefile b/docs/Makefile index 722210967c1b..686845d0e80c 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -120,7 +120,7 @@ docexes: cd .. && dune build docs/$(DOCERRORDIR)/error_doc.exe docs/$(DOCGENDIR)/rpc_doc.exe docs/$(DOCGENDIR)/p2p_doc.exe developer/metrics.csv: - ../tezos-node dump-metrics > developer/metrics.csv + ../octez-node dump-metrics > developer/metrics.csv $(ERRDOCEXE): docexes $(RPCDOCEXE): docexes diff --git a/docs/api/rpc-openapi.json b/docs/api/rpc-openapi.json index a013c64ca229..45ab378a09cd 100644 --- a/docs/api/rpc-openapi.json +++ b/docs/api/rpc-openapi.json @@ -1031,7 +1031,7 @@ ] }, "rules": { - "description": "Fine-grained logging instructions. Same format as described in `tezos-node run --help`, DEBUG section. In the example below, sections 'p2p' and all sections starting by 'client' will have their messages logged up to the debug level, whereas the rest of log sections will be logged up to the notice level.", + "description": "Fine-grained logging instructions. Same format as described in `octez-node run --help`, DEBUG section. In the example below, sections 'p2p' and all sections starting by 'client' will have their messages logged up to the debug level, whereas the rest of log sections will be logged up to the notice level.", "oneOf": [ { "$ref": "#/components/schemas/unistring" diff --git a/docs/developer/clic.rst b/docs/developer/clic.rst index 2011cf291d5a..52f689f08a3c 100644 --- a/docs/developer/clic.rst +++ b/docs/developer/clic.rst @@ -18,7 +18,7 @@ like this, thanks to ``tezos-clic``: ``clic`` is used for most of the binaries distributed with Octez, such as ``tezos-client`` and ``tezos-codec``. A notable exception is -``tezos-node`` which uses ``cmdliner``. +``octez-node`` which uses ``cmdliner``. In this tutorial, we will give a gentle introduction to ``clic`` by demonstrating how to implement a wallet command inspired by those of diff --git a/docs/developer/contributing.rst b/docs/developer/contributing.rst index a9031db248de..d44b161690a9 100644 --- a/docs/developer/contributing.rst +++ b/docs/developer/contributing.rst @@ -22,7 +22,7 @@ to search the existing issues before reporting a new one. Some information that are probably important to include in the description: the architecture (e.g. *ARM64*), the operating system (e.g. *Debian Stretch*), the network you are connected to (e.g. *Carthagenet*), the -binary or component (e.g. *tezos-node crashes* or *rpc X returns Y +binary or component (e.g. *octez-node crashes* or *rpc X returns Y while Z was expected*). Fixing typos diff --git a/docs/developer/openmetrics.rst b/docs/developer/openmetrics.rst index ee69ad4859d3..f5567f5239ce 100644 --- a/docs/developer/openmetrics.rst +++ b/docs/developer/openmetrics.rst @@ -35,7 +35,7 @@ The address defaults to localhost. When the option is not supplied at all, no metrics are produced. Ex.:: - tezos-node run --metrics-addr=:9091 + octez-node run --metrics-addr=:9091 To query the open metrics server the user can simply query the node. diff --git a/docs/developer/profiling.rst b/docs/developer/profiling.rst index 612377f2de12..5a1fb47f57f3 100644 --- a/docs/developer/profiling.rst +++ b/docs/developer/profiling.rst @@ -38,7 +38,7 @@ Memory profiling the OCaml heap :: M-x sturgeon-connect - tezos-nodememprof.1234.sturgeon + octez-nodememprof.1234.sturgeon (tab-completion works for finding the socket name) @@ -49,7 +49,7 @@ Memory profiling the C heap :: - valgrind --tool=massif tezos-node run ... + valgrind --tool=massif octez-node run ... - Stop with `Ctrl-C` then display with @@ -78,7 +78,7 @@ Performance profiling the ``--call-stack dwarf`` to get something more manageable, but interpreting the information can be harder. - - Let `perf` run ``tezos-node``: ``perf record -g -F 99 --call-graph=dwarf -- ./tezos-node run ...`` + - Let `perf` run ``octez-node``: ``perf record -g -F 99 --call-graph=dwarf -- ./octez-node run ...`` This will write ``perf.data`` after having stopped the node with ``Ctrl-C``. @@ -91,8 +91,8 @@ Performance profiling - `flamegraph `_: command-line tool for generating flamegraphs - (`example `__ for tezos-node) + (`example `__ for octez-node) - `gprof2dot `_: command-line tool for generating callgraphs - (`example `__ for tezos-node) + (`example `__ for octez-node) - `hotspot `_: a GUI for the `perf` tool diff --git a/docs/developer/proposal_testing.rst b/docs/developer/proposal_testing.rst index d12193025469..15024ffde582 100644 --- a/docs/developer/proposal_testing.rst +++ b/docs/developer/proposal_testing.rst @@ -369,10 +369,10 @@ For instance, the following commands import a context from the snapshot file into the folder ``/tmp/mainnet``, and generate an identity in the same folder:: - $ ./tezos-node snapshot import ~/snapshot-mainnet.rolling --data-dir /tmp/tezos-node-mainnet - $ ./tezos-node identity generate --data-dir /tmp/tezos-node-mainnet + $ ./octez-node snapshot import ~/snapshot-mainnet.rolling --data-dir /tmp/tezos-node-mainnet + $ ./octez-node identity generate --data-dir /tmp/tezos-node-mainnet -The ``./tezos-node snapshot import`` command accepts an option +The ``./octez-node snapshot import`` command accepts an option ``--block `` that instructs the command to check that the hash of the last block in the imported chain is ````. This mechanism helps the developer to check that the imported chain contains blocks that are part of @@ -475,7 +475,7 @@ In case we opted for not snapshotting the Alpha protocol, we could batch steps The script ``scripts/prepare_migration_test.sh`` receives an optional ```` as the last argument which, if passed, will be used for the -option ``--block `` to the ``./tezos-node snapshot import`` command +option ``--block `` to the ``./octez-node snapshot import`` command when importing the context form Mainnet. After performing the steps 1--7, the migration will be ready to be tested. The @@ -552,12 +552,12 @@ environment variable ``test-directory`` to the path of the test folder, such that we can run the node in the test folder later. Then it copies the contents of the original context folder into the test folder. -Now, we can run the ``tezos-node`` command by specifying the test folder +Now, we can run the ``octez-node`` command by specifying the test folder ``$test-directory`` as the data directory. We will also specify the RPC address ``localhost``, such that the RPCs will be available at the url ``localhost:8732``. In our example, by invoking the following:: - $ ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost & + $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost & We will now trigger the migration by baking blocks until the level reaches the one specified when setting the user-activated upgrades. The blocks can be baked @@ -597,7 +597,7 @@ copy the context of the original folder into the test folder. In our example:: Now we run the node in the test folder by invoking:: - $ ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost & + $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost & And finally, we bake the numbers of blocks specified by the user-activated upgrade, with the command:: @@ -713,8 +713,8 @@ invoking the following eight commands):: $ ./scripts/user_activated_upgrade.sh src/proto_012_* 1617344 $ ./scripts/patch-yes_node.sh $ make - $ ./tezos-node snapshot import ~/mainnet.rolling --data-dir /tmp/tezos-node-mainnet - $ ./tezos-node identity generate --data-dir /tmp/tezos-node-mainnet + $ ./octez-node snapshot import ~/mainnet.rolling --data-dir /tmp/tezos-node-mainnet + $ ./octez-node identity generate --data-dir /tmp/tezos-node-mainnet $ dune exec devtools/yes_wallet/yes_wallet.exe -- create from context /tmp/tezos-node-mainnet in /tmp/yes-wallet --active-bakers-only Copy original folder into test folder:: @@ -723,7 +723,7 @@ Copy original folder into test folder:: Run the node`:: - $ ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost & + $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost & Bake three blocks:: @@ -741,7 +741,7 @@ You should see the ``STITCHING!`` message! To test again, kill the node:: $ fg - ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost + ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost ^C Clean up by removing test folder and copying original folder into fresh @@ -753,7 +753,7 @@ test folder, and by removing files ``/tmp/yes-wallet/wallet_lock`` and Run the node:: - ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost & + ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost & And bake three blocks:: @@ -826,7 +826,7 @@ file ``~/mainnet.rolling`` into it. As explained in Section `Batch steps 1--7 above`_, the script ``scripts/prepare_migration_test.sh`` may receive an optional ```` parameter as the last argument which, if present, will be used for the option ``--block `` of the command -``./tezos-node snapshot import`` when importing the context form Mainnet. +``./octez-node snapshot import`` when importing the context form Mainnet. If we opt for not snapshotting the Alpha protocol, we can prepare the automatic migration with the same command as above, but omitting the optional name @@ -861,7 +861,7 @@ developer to be able to inspect the storage after the migration has been performed. Assume the temporary folder in our example is ``/tmp/tezt-526039``, the developer can start the node with the migrated context by invoking:: - $ ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost & + $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost & Once the node is up, it is possible to inspect the storage by using the Tezos client and/or the RPCs. New blocks can be baked with any of the accounts @@ -912,7 +912,7 @@ Run the migration test:: Run the resulting node (assuming temp folder ``/tmp/tezt-526039``):: - $ ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost & + $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost & Use the client, to manually inspect the storage, or for example to bake new blocks with the following command:: @@ -922,7 +922,7 @@ blocks with the following command:: To test again, kill the node:: $ fg - ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost + ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost ^C And run the migration test:: diff --git a/docs/developer/rpc.rst b/docs/developer/rpc.rst index efbffee28376..d7aab66a792d 100644 --- a/docs/developer/rpc.rst +++ b/docs/developer/rpc.rst @@ -9,7 +9,7 @@ network and just want to explore the RPC, you would run: :: - ./tezos-node run --rpc-addr localhost + ./octez-node run --rpc-addr localhost The RPC interface is self-documented and the ``tezos-client`` executable is able to pretty-print the RPC API. For instance, to see the API diff --git a/docs/developer/testing.rst b/docs/developer/testing.rst index 9209580800cb..05704011966a 100644 --- a/docs/developer/testing.rst +++ b/docs/developer/testing.rst @@ -174,7 +174,7 @@ Python testing and execution framework The Tezos project uses `pytest `_, a Python testing framework, combined with :doc:`tezos-launchers `, a Python wrapper -``tezos-node`` and ``tezos-client``, to perform integration testing +``octez-node`` and ``tezos-client``, to perform integration testing of the node, the client, networks of nodes and daemons such as the baker and endorser. @@ -435,7 +435,7 @@ guidelines: For system test frameworks System test frameworks, as :doc:`tezt` and :doc:`python_testing_framework`, run binaries e.g. ``tezos-client`` and - ``tezos-node``. Typically, they do so with calls to ``exec`` so the + ``octez-node``. Typically, they do so with calls to ``exec`` so the resulting process does not inherit the signal handlers from the parent process (the test framework). When writing tests in these frameworks, the author must ensure that the processes launched are diff --git a/docs/developer/time_measurement_ppx.rst b/docs/developer/time_measurement_ppx.rst index fb5ec97eb407..3c975fa0ad69 100644 --- a/docs/developer/time_measurement_ppx.rst +++ b/docs/developer/time_measurement_ppx.rst @@ -189,7 +189,7 @@ The PPX provides the handling of three attributes: Some of these attributes are used, for instance, in the implementation of the :ref:`performance regression test framework `. -Instrumenting the tezos-node executable +Instrumenting the octez-node executable --------------------------------------- A helper has been added in the ``Makefile``, so you just need to run the following diff --git a/docs/introduction/howtoget.rst b/docs/introduction/howtoget.rst index bae01a21856c..46835a007ae2 100644 --- a/docs/introduction/howtoget.rst +++ b/docs/introduction/howtoget.rst @@ -147,7 +147,7 @@ Using Docker Images And Docker-Compose For every change committed in the GitLab repository, Docker images are automatically generated and published on `DockerHub `_. This provides a convenient -way to run an always up-to-date ``tezos-node``. +way to run an always up-to-date ``octez-node``. One way to run those Docker images is with `docker-compose `_. We provide ``docker-compose`` files for all active @@ -336,10 +336,10 @@ Now, install all the binaries by: :start-after: [install tezos] :end-before: [test executables] -You can be more specific and only ``opam install tezos-node``, ``opam +You can be more specific and only ``opam install octez-node``, ``opam install octez-baker-alpha``, ... In that case, it is enough to install the system dependencies of this package only by running ``opam depext -tezos-node`` for example instead of ``opam depext tezos``. +octez-node`` for example instead of ``opam depext tezos``. .. warning:: diff --git a/docs/introduction/howtouse.rst b/docs/introduction/howtouse.rst index 3ea6287b9133..acdf7e37cabb 100644 --- a/docs/introduction/howtouse.rst +++ b/docs/introduction/howtouse.rst @@ -15,7 +15,7 @@ The Binaries After a successful compilation, you should have the following binaries: -- ``tezos-node``: the tezos daemon itself (see `Node`_); +- ``octez-node``: the tezos daemon itself (see `Node`_); - ``tezos-client``: a command-line client and basic wallet (see `Client`_); - ``tezos-admin-client``: administration tool for the node (see :ref:`tezos-admin-client`); - ``octez-{baker,accuser}-*``: daemons to bake and accuse on the Tezos network (see :doc:`howtorun`); @@ -23,7 +23,7 @@ After a successful compilation, you should have the following binaries: - ``tezos-validator``: a daemon for validating and applying operations in blocks (see `Validator`_) - ``tezos-signer``: a client to remotely sign operations or blocks (see :ref:`signer`); -- ``tezos-proxy-server``: a readonly frontend to ``tezos-node`` designed to lower the load of full nodes (see :doc:`../user/proxy-server`) +- ``tezos-proxy-server``: a readonly frontend to ``octez-node`` designed to lower the load of full nodes (see :doc:`../user/proxy-server`) - ``tezos-codec``: a utility for documenting the data encodings and for performing data encoding/decoding (see `Codec`_) - ``tezos-protocol-compiler``: a domain-specific compiler for Tezos protocols (see `Protocol compiler`_) - ``tezos-snoop``: a tool for modeling the performance of any piece of OCaml code, based on benchmarking (see :doc:`../developer/snoop`) @@ -33,7 +33,7 @@ bound to, and up to some version, also by its number. For instance, ``octez-baker-014-PtKathma`` is the baker for the Kathmandu protocol, and ``octez-baker-alpha`` is the baker of the development protocol. -The ``tezos-node`` daemon is not suffixed by any protocol name, because it is independent of the economic protocol. See also the `Node's Protocol`_ section below. +The ``octez-node`` daemon is not suffixed by any protocol name, because it is independent of the economic protocol. See also the `Node's Protocol`_ section below. Read The Manual @@ -122,7 +122,7 @@ Node Identity First, we need to generate a new identity for the node to connect to the network:: - tezos-node identity generate + octez-node identity generate .. note:: @@ -198,7 +198,7 @@ internet. With the following command, it is available uniquely on the :: - tezos-node run --rpc-addr 127.0.0.1 + octez-node run --rpc-addr 127.0.0.1 Node configuration ~~~~~~~~~~~~~~~~~~ @@ -213,7 +213,7 @@ Many options of the node can be configured when running the node: The list of configurable options can be obtained using the following command:: - tezos-node run --help + octez-node run --help You can read more about the :doc:`node configuration <../user/node-configuration>` and its :ref:`private mode `. @@ -231,11 +231,11 @@ Putting together all the above instructions, you may want to run a node as follo # Download a snapshot for your target network, e.g. : wget -O # Configure the node for running on : - tezos-node config init --data-dir ~/.tezos-node- --network + octez-node config init --data-dir ~/.tezos-node- --network # Import the snapshot into the node data directory: - tezos-node snapshot import --data-dir ~/.tezos-node- --block + octez-node snapshot import --data-dir ~/.tezos-node- --block # Run the node: - tezos-node run --data-dir ~/.tezos-node- --rpc-addr 127.0.0.1 + octez-node run --data-dir ~/.tezos-node- --rpc-addr 127.0.0.1 .. _howtouse_tezos_client: @@ -640,7 +640,7 @@ In this short tutorial we will not use some other binaries, but let as briefly r Validator ~~~~~~~~~ -The Tezos validator (``tezos-validator``) is an auxiliary daemon that is launched by ``tezos-node`` in order to validate operations in parallel to its main process (unless the option ``--singleprocess`` is given). +The Tezos validator (``tezos-validator``) is an auxiliary daemon that is launched by ``octez-node`` in order to validate operations in parallel to its main process (unless the option ``--singleprocess`` is given). It also applies the valid operations in a block and computes the resulting context. It is not meant to be invoked directly by users. @@ -650,7 +650,7 @@ Codec The Tezos codec (``tezos-codec``) is a utility that: -- provides documentation for all the encodings used in the ``tezos-node`` (and other binaries), and +- provides documentation for all the encodings used in the ``octez-node`` (and other binaries), and - allows to convert from JSON to binary and vice-versa for all these encodings. It is meant to be used by developers for tests, for generating documentation when writing libraries that share data with the node, for light scripting, etc. diff --git a/docs/shell/cli-commands.rst b/docs/shell/cli-commands.rst index 2e63c317b52d..5f65629aa797 100644 --- a/docs/shell/cli-commands.rst +++ b/docs/shell/cli-commands.rst @@ -58,7 +58,7 @@ Node manual The command line of the Tezos node is not currently documented as a web page, but you can obtain it in Unix manual format by running the node with no arguments:: - tezos-node + octez-node The above command briefly shows the available node commands. Each command accepts its own set of options and arguments, see :doc:`../user/node-configuration`. diff --git a/docs/user/history_modes.rst b/docs/user/history_modes.rst index d1a2e00d00c0..28aa668bccf6 100644 --- a/docs/user/history_modes.rst +++ b/docs/user/history_modes.rst @@ -105,7 +105,7 @@ To run a ``full`` node you can either use the command line arguments: .. code-block:: console - tezos-node run --history-mode full + octez-node run --history-mode full or use your configuration file as described in :doc:`here `: @@ -141,7 +141,7 @@ To run a ``rolling`` node you can either use the command line arguments: .. code-block:: console - tezos-node run --history-mode experimental-rolling + octez-node run --history-mode experimental-rolling or use your configuration file as described in :doc:`here `: @@ -165,7 +165,7 @@ Setting up a node in archive mode --------------------------------- To run an ``archive`` node you can use the command line arguments: -``$ tezos-node run --history-mode archive`` +``$ octez-node run --history-mode archive`` Or the configuration file: ``{ "shell": {"history_mode": "archive"} }`` @@ -255,6 +255,6 @@ there are some restrictions when switching from one mode to another. +---------+---------+------+---------+ (*) Switching from a ``full`` node to an ``archive`` one is possible -using the ``reconstruct`` feature. To do so, run ``tezos-node +using the ``reconstruct`` feature. To do so, run ``octez-node reconstruct`` on your node. Note that the storage reconstruction is a long process that, on the main network, may requires days to complete. diff --git a/docs/user/logging.rst b/docs/user/logging.rst index 7d522ee29498..11aaca44be20 100644 --- a/docs/user/logging.rst +++ b/docs/user/logging.rst @@ -237,7 +237,7 @@ Node-Specific Configuration Configuration File ~~~~~~~~~~~~~~~~~~ -See ``tezos-node config --help`` for the full schema of the node’s JSON +See ``octez-node config --help`` for the full schema of the node’s JSON configuration file. In particular the fields: @@ -251,7 +251,7 @@ In particular the fields: Command Line Options ~~~~~~~~~~~~~~~~~~~~ -See ``tezos-node run --help``, the ``lwt-log://`` sink configuration can +See ``octez-node run --help``, the ``lwt-log://`` sink configuration can be also changed with 2 options: - ``-v`` / ``-vv``: set the global log level to ``Info`` or ``Debug`` diff --git a/docs/user/multinetwork.rst b/docs/user/multinetwork.rst index 2cbeaf779923..3c575becce3f 100644 --- a/docs/user/multinetwork.rst +++ b/docs/user/multinetwork.rst @@ -34,9 +34,9 @@ Built-In Networks The simplest way to select the network to connect to is to use the ``--network`` option when you initialize your :doc:`node configuration <./node-configuration>`. For instance, to run on Limanet:: - tezos-node config init --data-dir ~/tezos-limanet --network limanet - tezos-node identity generate --data-dir ~/tezos-limanet - tezos-node run --data-dir ~/tezos-limanet + octez-node config init --data-dir ~/tezos-limanet --network limanet + octez-node identity generate --data-dir ~/tezos-limanet + octez-node run --data-dir ~/tezos-limanet .. note:: Once initialized, the node remembers its network settings on subsequent runs @@ -60,11 +60,11 @@ the following built-in networks: If you did not initialize your node configuration, or if your configuration file contains no ``network`` field, the node assumes you want to run Mainnet. -You can use the ``--network`` option with ``tezos-node run`` to make sure +You can use the ``--network`` option with ``octez-node run`` to make sure your node runs on the expected network. For instance, to make sure that it runs on Limanet:: - tezos-node run --data-dir ~/tezos-limanet --network limanet + octez-node run --data-dir ~/tezos-limanet --network limanet This command will fail with an error if the configured network is not Limanet. The node also displays the chain name (such as ``TEZOS_MAINNET``) when it starts. diff --git a/docs/user/node-config.sh b/docs/user/node-config.sh index 20086afc36ca..9deac52317dc 100755 --- a/docs/user/node-config.sh +++ b/docs/user/node-config.sh @@ -5,14 +5,14 @@ # [remove config file if exists] rm -f tmp/config.json # [initialize config file] -./tezos-node config init --config-file=tmp/config.json --network=sandbox +./octez-node config init --config-file=tmp/config.json --network=sandbox # [update config file] -./tezos-node config update --config-file=tmp/config.json --data-dir=tmp \ +./octez-node config update --config-file=tmp/config.json --data-dir=tmp \ --peer="[::]:10732" --peer="192.168.1.3:9733" \ --private-mode \ --rpc-addr="localhost:8733" --net-addr="1.2.3.4" \ --connections=25 \ - --log-output="tezos-node.log" \ + --log-output="octez-node.log" \ --history-mode=full # [show config file] -./tezos-node config show --data-dir=tmp +./octez-node config show --data-dir=tmp diff --git a/docs/user/node-configuration.rst b/docs/user/node-configuration.rst index da2208f1da19..d05092579f80 100644 --- a/docs/user/node-configuration.rst +++ b/docs/user/node-configuration.rst @@ -15,7 +15,7 @@ When the same parameter is set both in the configuration file and using a comman The list of configurable options on the command line interface (CLI) can be obtained using the following command:: - tezos-node run --help + octez-node run --help .. _node-conf-file: @@ -24,17 +24,17 @@ Configuration file Parameters in the configuration file can be specified in two different ways: -- by creating and updating the configuration file using the ``config`` command of ``tezos-node``. This covers a subset of the CLI of the ``run`` command of ``tezos-node`` mentioned above. +- by creating and updating the configuration file using the ``config`` command of ``octez-node``. This covers a subset of the CLI of the ``run`` command of ``octez-node`` mentioned above. The list of parameters configurable via the ``config`` command can be obtained using the following command:: - tezos-node config update --help + octez-node config update --help -- by directly editing the configuration file. This allows to specify all the available configuration parameters, including some that cannot be set using the options of the ``config`` and ``run`` commands of ``tezos-node``, for example network parameters such as connection or authentication timeouts. +- by directly editing the configuration file. This allows to specify all the available configuration parameters, including some that cannot be set using the options of the ``config`` and ``run`` commands of ``octez-node``, for example network parameters such as connection or authentication timeouts. The list of configurable parameters in the configuration file can be obtained using the following command:: - tezos-node config --help + octez-node config --help This command also explains the role of each option and parameter and the range of possible values. @@ -43,7 +43,7 @@ The config command :: - ./tezos-node config init + ./octez-node config init This will initialize a configuration file for the node in ``$HOME/.tezos-node/config.json``, using default values. It only @@ -60,11 +60,11 @@ The easiest way to amend this default configuration is to use :: # Update the config file: - tezos-node config update <…> + octez-node config update <…> # Check your new values: - tezos-node config show + octez-node config show # If you want to restart from an empty cfg file: - tezos-node config reset <…> + octez-node config reset <…> However, note that the ``network`` configuration parameter, needed to run the node on a network other than the default one (Mainnet), can only be defined when the configuration file is initialized (using ``init``), and cannot be updated later (using ``update``). See the instructions for :doc:`running the node in test networks <./multinetwork>`. @@ -79,12 +79,12 @@ Editing the configuration file All blockchain data is stored under ``$HOME/.tezos-node/`` by default. You can -change this by doing ``./tezos-node config update --data-dir +change this by doing ``./octez-node config update --data-dir ``. To run multiple nodes on the same machine, you can duplicate and edit ``$HOME/.tezos-node/config.json`` while making sure they don't share -the same ``data-dir``. Then run your node with ``./tezos-node +the same ``data-dir``. Then run your node with ``./octez-node run --config-file=``. Here is an example configuration file with several parameters specified. @@ -169,10 +169,10 @@ character, which stands for any whole path segment (i.e. it's not allowed to mix with other characters in a path segment). A ``**`` stands for any possible path suffix. -Additionally ``--allow-all-rpc`` CLI option to ``tezos-node`` can be used to +Additionally ``--allow-all-rpc`` CLI option to ``octez-node`` can be used to simply allow all RPC endpoints on a given address. When passed to -``tezos-node config`` command, this option modifies the ``config.json`` file, -putting an appropriate ACL there. When passed to ``tezos-node run``, it +``octez-node config`` command, this option modifies the ``config.json`` file, +putting an appropriate ACL there. When passed to ``octez-node run``, it overrides the settings of the ``config.json`` for this particular run, without modifying the file. @@ -195,7 +195,7 @@ Examples :: - $ tezos-node run --rpc-addr localhost:8732 + $ octez-node run --rpc-addr localhost:8732 In this case the RPC is only available for requests coming from ``localhost`` (i.e. ``127.0.0.1``). There's no need configure the ACL, as an allow-all policy @@ -203,7 +203,7 @@ is applied to the local host by default. :: - $ tezos-node run --rpc-addr localhost:8732 --rpc-addr 192.168.0.3:8732 + $ octez-node run --rpc-addr localhost:8732 --rpc-addr 192.168.0.3:8732 In this example the RPC is available to both ``localhost`` and to the local network (assuming the node does have address ``192.168.0.3`` in that network). @@ -214,7 +214,7 @@ be filtered by the default ACL (:ref:`see below `). In this last case, to listen on both ``localhost`` and local network, it might be tempting to listen on the special ``0.0.0.0`` address:: - $ tezos-node run --rpc-addr 0.0.0.0:8732 + $ octez-node run --rpc-addr 0.0.0.0:8732 ``0.0.0.0`` is a special address, not attached to any particular networking interface. Instead it tells the OS to route messages incoming to **all** @@ -230,11 +230,11 @@ remote hosts, but enable all RPCs for localhost (which is for instance necessary to perform baking and endorsing). Since all RPCs are available to localhost by default, it is sufficient to open another listening address:: - $ tezos-node run --rpc-addr localhost --rpc-addr 0.0.0.0 + $ octez-node run --rpc-addr localhost --rpc-addr 0.0.0.0 The ``--allow-all-rpc`` switch can be used to open all RPCs on a specific address:: - $ tezos-node run --rpc-addr 192.168.0.3 --allow-all-rpc 192.168.0.3 + $ octez-node run --rpc-addr 192.168.0.3 --allow-all-rpc 192.168.0.3 Note that the addresses of both ``--rpc-addr`` and ``--allow-all-rpc`` switches should match. In particular remember that ``0.0.0.0`` is a specific address @@ -354,7 +354,7 @@ hardware wallet. :: - tezos-node run --rpc-addr [::] --private-mode \ + octez-node run --rpc-addr [::] --private-mode \ --no-bootstrap-peers \ --synchronisation-threshold=1 \ --connections 1 \ diff --git a/docs/user/proxy-server.rst b/docs/user/proxy-server.rst index 8d602763d28b..a824439b8d3e 100644 --- a/docs/user/proxy-server.rst +++ b/docs/user/proxy-server.rst @@ -1,7 +1,7 @@ Proxy server ------------ -This page describes the *proxy server*, a readonly frontend to ``tezos-node`` +This page describes the *proxy server*, a readonly frontend to ``octez-node`` which is designed to lower the load of full nodes. It can be run separately from a node and will handle some RPC requests by itself. It is named after two things: @@ -64,7 +64,7 @@ In a terminal, start a sandboxed node: $ ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 1 April 21 11:05:32.789 - node.config.validation: the node configuration has been successfully validated. - Created /tmp/tezos-node.Uzq5aGAN/config.json for network: sandbox. + Created /tmp/octez-node.Uzq5aGAN/config.json for network: sandbox. ... Leave that terminal running. In a second terminal, prepare the appropriate @@ -194,12 +194,12 @@ and restart it as follows: :: - $ ./tezos-proxy-server --endpoint http://127.0.0.1:18731 --rpc-addr http://127.0.0.1:18732 --data-dir /tmp/tezos-node.Uzq5aGAN + $ ./tezos-proxy-server --endpoint http://127.0.0.1:18731 --rpc-addr http://127.0.0.1:18732 --data-dir /tmp/octez-node.Uzq5aGAN protocol of proxy unspecified, using the node's protocol: ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK Apr 21 11:09:22.092 - proxy_server_run: starting proxy RPC server on 127.0.0.1:18732 The value of the ``--data-dir`` argument was obtained by looking at the -output of the terminal where ``tezos-node`` was launched +output of the terminal where ``octez-node`` was launched (see :ref:`above `). Now, in the fourth terminal (the client's terminal), redo the request diff --git a/docs/user/sandbox.rst b/docs/user/sandbox.rst index d0426377c7fc..d8bff9eebf3f 100644 --- a/docs/user/sandbox.rst +++ b/docs/user/sandbox.rst @@ -24,7 +24,7 @@ for peers on port ``19731`` and listening for RPC on port ``18731``. ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 1 This node will store its data in a temporary directory -``/tmp/tezos-node.xxxxxxxx`` which will be removed when the node is +``/tmp/octez-node.xxxxxxxx`` which will be removed when the node is stopped. The option ``--connections`` is just to remove the spurious “Too few connections” warnings by lowering the number of expected connection. diff --git a/docs/user/snapshots.rst b/docs/user/snapshots.rst index 6dac8d6b4c92..e87a35cca084 100644 --- a/docs/user/snapshots.rst +++ b/docs/user/snapshots.rst @@ -49,7 +49,7 @@ will not work), run: .. code-block:: console - tezos-node snapshot import --block [--data-dir ] + octez-node snapshot import --block [--data-dir ] The ``--block `` option argument aims to verify that the block contained in the snapshot is the one that you are expecting to @@ -83,7 +83,7 @@ This information is displayed by the following command: .. code-block:: console - tezos-node snapshot info + octez-node snapshot info As can be seen in the snapshot information, a snapshot contains historical data corresponding to a given history mode, which can be: @@ -118,7 +118,7 @@ point. This kind of snapshot can only be created from a ``full`` or an .. code-block:: console - tezos-node snapshot export --block + octez-node snapshot export --block The ```` hint can be given as a *block hash*, a *block level*, an alias (*head*, *savepoint* or *checkpoint*) and a relative block @@ -134,7 +134,7 @@ snapshot file name can be given as an additional argument. For example: .. code-block:: console - tezos-node snapshot export recent_head_snapshot.full --block head + octez-node snapshot export recent_head_snapshot.full --block head Rolling export ~~~~~~~~~~~~~~ @@ -148,7 +148,7 @@ history. .. code-block:: console - tezos-node snapshot export .rolling --block --rolling + octez-node snapshot export .rolling --block --rolling Snapshot file format and IPFS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- GitLab From 197c46e5e38853e9d01a62b44bf015f4fe6a39bf Mon Sep 17 00:00:00 2001 From: Richard Davison Date: Fri, 9 Sep 2022 16:05:22 -0400 Subject: [PATCH 03/13] Docs: octez-client --- docs/CHANGES.rst | 22 +++--- docs/Makefile | 6 +- docs/alpha/cli-commands.rst | 4 +- docs/alpha/consensus.rst | 4 +- docs/alpha/global_constants.rst | 6 +- docs/alpha/plugins.rst | 10 +-- docs/alpha/sapling.rst | 40 +++++------ docs/alpha/transaction_rollups.rst | 22 +++--- docs/alpha/voting.rst | 14 ++-- docs/api/kathmandu-mempool-openapi.json | 2 +- docs/developer/clic.rst | 22 +++--- docs/developer/encodings.rst | 14 ++-- docs/developer/long-tezts.rst | 2 +- docs/developer/proposal_testing.rst | 40 +++++------ docs/developer/python_testing_framework.rst | 16 ++--- docs/developer/rpc.rst | 8 +-- docs/developer/testing.rst | 8 +-- docs/include/rpc_introduction.rst.inc | 4 +- docs/introduction/howtoget.rst | 2 +- docs/introduction/howtorun.rst | 12 ++-- docs/introduction/howtouse.rst | 42 ++++++------ docs/introduction/install-opam-scratch.sh | 2 +- docs/kathmandu/cli-commands.rst | 4 +- docs/kathmandu/consensus.rst | 4 +- docs/kathmandu/global_constants.rst | 6 +- docs/kathmandu/plugins.rst | 10 +-- docs/kathmandu/sapling.rst | 40 +++++------ docs/kathmandu/transaction_rollups.rst | 22 +++--- docs/kathmandu/voting.rst | 14 ++-- docs/lima/cli-commands.rst | 4 +- docs/lima/consensus.rst | 4 +- docs/lima/global_constants.rst | 6 +- docs/lima/plugins.rst | 10 +-- docs/lima/sapling.rst | 40 +++++------ docs/lima/transaction_rollups.rst | 22 +++--- docs/lima/voting.rst | 14 ++-- docs/michelson/michelson-meta.yaml | 2 +- docs/shell/rpc_introduction.rst.inc | 4 +- docs/user/fa12.rst | 20 +++--- docs/user/history_modes.rst | 2 +- docs/user/key-management.rst | 48 ++++++------- docs/user/light.rst | 16 ++--- docs/user/logging.rst | 4 +- docs/user/mockup.rst | 26 +++---- docs/user/multinetwork.rst | 2 +- docs/user/multisig.rst | 76 ++++++++++----------- docs/user/node-configuration.rst | 2 +- docs/user/proxy-server.rst | 12 ++-- docs/user/proxy.rst | 14 ++-- docs/user/sandbox.rst | 12 ++-- docs/user/various.rst | 4 +- docs/user/versioning.rst | 2 +- 52 files changed, 374 insertions(+), 374 deletions(-) diff --git a/docs/CHANGES.rst b/docs/CHANGES.rst index 492e3352fdd1..ada3fe56c205 100644 --- a/docs/CHANGES.rst +++ b/docs/CHANGES.rst @@ -330,7 +330,7 @@ Client - Client now allows to simulate failing operations with ``--simulation --force``, and report errors without specifying limits. -- Added ``--ignore-case`` option to the ``tezos-client gen vanity keys`` command +- Added ``--ignore-case`` option to the ``octez-client gen vanity keys`` command to allow case-insensitive search for the given pattern. Proxy Server @@ -661,7 +661,7 @@ Node - Fixed missing removal of replaced operation in the plugin when another better one takes its place (when the mempool is full). -- The output of ``tezos-client get ledger high watermark for `` +- The output of ``octez-client get ledger high watermark for `` now also displays the high-water mark for the round, if available. Rounds are introduced in Tenderbake. @@ -867,7 +867,7 @@ Node - The prevalidator (which handles operations which have been received but not yet included in a block) was made more restrictive: it now accepts a single manager operation from a given manager for a given block. This limitation - was already present implicitly if you were using the ``tezos-client`` commands. + was already present implicitly if you were using the ``octez-client`` commands. Batches of operations can be used to get around this restriction, see the ``multiple transfers`` command to learn more. In addition, operations rejected because of this limitation are solely delayed to a future block. @@ -1146,9 +1146,9 @@ Node Client ------ -- Disabled indentation checking by default in the ``tezos-client - convert script`` and ``tezos-client hash script`` commands. In - particular, ``tezos-client convert script