From 63b95779cebb10dadf385b1e0e13c899b2922d1b Mon Sep 17 00:00:00 2001 From: Peter Rabbitson Date: Fri, 14 Jun 2024 03:34:36 +0200 Subject: [PATCH] chore: curio: remove forgotten parts of curio config (#12087) --- .github/workflows/test.yml | 3 +- .gitignore | 1 - node/config/doc_gen.go | 503 ------------------------------------- node/config/types.go | 306 ---------------------- 4 files changed, 1 insertion(+), 812 deletions(-) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 2a5648a54..fe54a21de 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -147,8 +147,7 @@ jobs: "itest-worker", "multicore-sdr", "unit-cli", - "unit-storage", - "itest-curio" + "unit-storage" ] run: | # Create a list of integration test groups diff --git a/.gitignore b/.gitignore index a40ab0bd5..93b79479a 100644 --- a/.gitignore +++ b/.gitignore @@ -6,7 +6,6 @@ /lotus-chainwatch /lotus-shed /lotus-sim -/curio /sptool /lotus-townhall /lotus-fountain diff --git a/node/config/doc_gen.go b/node/config/doc_gen.go index 3f66344c8..a33606277 100644 --- a/node/config/doc_gen.go +++ b/node/config/doc_gen.go @@ -117,509 +117,6 @@ your node if metadata log is disabled`, Comment: ``, }, }, - "CurioAddresses": { - { - Name: "PreCommitControl", - Type: "[]string", - - Comment: `Addresses to send PreCommit messages from`, - }, - { - Name: "CommitControl", - Type: "[]string", - - Comment: `Addresses to send Commit messages from`, - }, - { - Name: "TerminateControl", - Type: "[]string", - - Comment: ``, - }, - { - Name: "DisableOwnerFallback", - Type: "bool", - - Comment: `DisableOwnerFallback disables usage of the owner address for messages -sent automatically`, - }, - { - Name: "DisableWorkerFallback", - Type: "bool", - - Comment: `DisableWorkerFallback disables usage of the worker address for messages -sent automatically, if control addresses are configured. -A control address that doesn't have enough funds will still be chosen -over the worker address if this flag is set.`, - }, - { - Name: "MinerAddresses", - Type: "[]string", - - Comment: `MinerAddresses are the addresses of the miner actors to use for sending messages`, - }, - }, - "CurioAlerting": { - { - Name: "PagerDutyEventURL", - Type: "string", - - Comment: `PagerDutyEventURL is URL for PagerDuty.com Events API v2 URL. Events sent to this API URL are ultimately -routed to a PagerDuty.com service and processed. -The default is sufficient for integration with the stock commercial PagerDuty.com company's service.`, - }, - { - Name: "PageDutyIntegrationKey", - Type: "string", - - Comment: `PageDutyIntegrationKey is the integration key for a PagerDuty.com service. You can find this unique service -identifier in the integration page for the service.`, - }, - { - Name: "MinimumWalletBalance", - Type: "types.FIL", - - Comment: `MinimumWalletBalance is the minimum balance all active wallets. If the balance is below this value, an -alerts will be triggered for the wallet`, - }, - }, - "CurioConfig": { - { - Name: "Subsystems", - Type: "CurioSubsystemsConfig", - - Comment: ``, - }, - { - Name: "Fees", - Type: "CurioFees", - - Comment: ``, - }, - { - Name: "Addresses", - Type: "[]CurioAddresses", - - Comment: `Addresses of wallets per MinerAddress (one of the fields).`, - }, - { - Name: "Proving", - Type: "CurioProvingConfig", - - Comment: ``, - }, - { - Name: "Ingest", - Type: "CurioIngestConfig", - - Comment: ``, - }, - { - Name: "Journal", - Type: "JournalConfig", - - Comment: ``, - }, - { - Name: "Apis", - Type: "ApisConfig", - - Comment: ``, - }, - { - Name: "Alerting", - Type: "CurioAlerting", - - Comment: ``, - }, - }, - "CurioFees": { - { - Name: "DefaultMaxFee", - Type: "types.FIL", - - Comment: ``, - }, - { - Name: "MaxPreCommitGasFee", - Type: "types.FIL", - - Comment: ``, - }, - { - Name: "MaxCommitGasFee", - Type: "types.FIL", - - Comment: ``, - }, - { - Name: "MaxPreCommitBatchGasFee", - Type: "BatchFeeConfig", - - Comment: `maxBatchFee = maxBase + maxPerSector * nSectors`, - }, - { - Name: "MaxCommitBatchGasFee", - Type: "BatchFeeConfig", - - Comment: ``, - }, - { - Name: "MaxTerminateGasFee", - Type: "types.FIL", - - Comment: ``, - }, - { - Name: "MaxWindowPoStGasFee", - Type: "types.FIL", - - Comment: `WindowPoSt is a high-value operation, so the default fee should be high.`, - }, - { - Name: "MaxPublishDealsFee", - Type: "types.FIL", - - Comment: ``, - }, - }, - "CurioIngestConfig": { - { - Name: "MaxQueueSDR", - Type: "int", - - Comment: `Maximum number of sectors that can be queued waiting for SDR to start processing. -0 = unlimited -Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem. -The SDR queue includes deals which are in the process of entering the sealing pipeline - size of this queue -will also impact the maximum number of ParkPiece tasks which can run concurrently. - -SDR queue is the first queue in the sealing pipeline, meaning that it should be used as the primary backpressure mechanism.`, - }, - { - Name: "MaxQueueTrees", - Type: "int", - - Comment: `Maximum number of sectors that can be queued waiting for SDRTrees to start processing. -0 = unlimited -Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem. -In case of the trees tasks it is possible that this queue grows more than this limit, the backpressure is only -applied to sectors entering the pipeline.`, - }, - { - Name: "MaxQueuePoRep", - Type: "int", - - Comment: `Maximum number of sectors that can be queued waiting for PoRep to start processing. -0 = unlimited -Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem. -Like with the trees tasks, it is possible that this queue grows more than this limit, the backpressure is only -applied to sectors entering the pipeline.`, - }, - }, - "CurioProvingConfig": { - { - Name: "ParallelCheckLimit", - Type: "int", - - Comment: `Maximum number of sector checks to run in parallel. (0 = unlimited) - -WARNING: Setting this value too high may make the node crash by running out of stack -WARNING: Setting this value too low may make sector challenge reading much slower, resulting in failed PoSt due -to late submission. - -After changing this option, confirm that the new value works in your setup by invoking -'lotus-miner proving compute window-post 0'`, - }, - { - Name: "SingleCheckTimeout", - Type: "Duration", - - Comment: `Maximum amount of time a proving pre-check can take for a sector. If the check times out the sector will be skipped - -WARNING: Setting this value too low risks in sectors being skipped even though they are accessible, just reading the -test challenge took longer than this timeout -WARNING: Setting this value too high risks missing PoSt deadline in case IO operations related to this sector are -blocked (e.g. in case of disconnected NFS mount)`, - }, - { - Name: "PartitionCheckTimeout", - Type: "Duration", - - Comment: `Maximum amount of time a proving pre-check can take for an entire partition. If the check times out, sectors in -the partition which didn't get checked on time will be skipped - -WARNING: Setting this value too low risks in sectors being skipped even though they are accessible, just reading the -test challenge took longer than this timeout -WARNING: Setting this value too high risks missing PoSt deadline in case IO operations related to this partition are -blocked or slow`, - }, - { - Name: "DisableWDPoStPreChecks", - Type: "bool", - - Comment: `Disable WindowPoSt provable sector readability checks. - -In normal operation, when preparing to compute WindowPoSt, lotus-miner will perform a round of reading challenges -from all sectors to confirm that those sectors can be proven. Challenges read in this process are discarded, as -we're only interested in checking that sector data can be read. - -When using builtin proof computation (no PoSt workers, and DisableBuiltinWindowPoSt is set to false), this process -can save a lot of time and compute resources in the case that some sectors are not readable - this is caused by -the builtin logic not skipping snark computation when some sectors need to be skipped. - -When using PoSt workers, this process is mostly redundant, with PoSt workers challenges will be read once, and -if challenges for some sectors aren't readable, those sectors will just get skipped. - -Disabling sector pre-checks will slightly reduce IO load when proving sectors, possibly resulting in shorter -time to produce window PoSt. In setups with good IO capabilities the effect of this option on proving time should -be negligible. - -NOTE: It likely is a bad idea to disable sector pre-checks in setups with no PoSt workers. - -NOTE: Even when this option is enabled, recovering sectors will be checked before recovery declaration message is -sent to the chain - -After changing this option, confirm that the new value works in your setup by invoking -'lotus-miner proving compute window-post 0'`, - }, - { - Name: "MaxPartitionsPerPoStMessage", - Type: "int", - - Comment: `Maximum number of partitions to prove in a single SubmitWindowPoSt messace. 0 = network limit (3 in nv21) - -A single partition may contain up to 2349 32GiB sectors, or 2300 64GiB sectors. -// -Note that setting this value lower may result in less efficient gas use - more messages will be sent, -to prove each deadline, resulting in more total gas use (but each message will have lower gas limit) - -Setting this value above the network limit has no effect`, - }, - { - Name: "MaxPartitionsPerRecoveryMessage", - Type: "int", - - Comment: `In some cases when submitting DeclareFaultsRecovered messages, -there may be too many recoveries to fit in a BlockGasLimit. -In those cases it may be necessary to set this value to something low (eg 1); -Note that setting this value lower may result in less efficient gas use - more messages will be sent than needed, -resulting in more total gas use (but each message will have lower gas limit)`, - }, - { - Name: "SingleRecoveringPartitionPerPostMessage", - Type: "bool", - - Comment: `Enable single partition per PoSt Message for partitions containing recovery sectors - -In cases when submitting PoSt messages which contain recovering sectors, the default network limit may still be -too high to fit in the block gas limit. In those cases, it becomes useful to only house the single partition -with recovering sectors in the post message - -Note that setting this value lower may result in less efficient gas use - more messages will be sent, -to prove each deadline, resulting in more total gas use (but each message will have lower gas limit)`, - }, - }, - "CurioSubsystemsConfig": { - { - Name: "EnableWindowPost", - Type: "bool", - - Comment: `EnableWindowPost enables window post to be executed on this curio instance. Each machine in the cluster -with WindowPoSt enabled will also participate in the window post scheduler. It is possible to have multiple -machines with WindowPoSt enabled which will provide redundancy, and in case of multiple partitions per deadline, -will allow for parallel processing of partitions. - -It is possible to have instances handling both WindowPoSt and WinningPoSt, which can provide redundancy without -the need for additional machines. In setups like this it is generally recommended to run -partitionsPerDeadline+1 machines.`, - }, - { - Name: "WindowPostMaxTasks", - Type: "int", - - Comment: ``, - }, - { - Name: "EnableWinningPost", - Type: "bool", - - Comment: `EnableWinningPost enables winning post to be executed on this curio instance. -Each machine in the cluster with WinningPoSt enabled will also participate in the winning post scheduler. -It is possible to mix machines with WindowPoSt and WinningPoSt enabled, for details see the EnableWindowPost -documentation.`, - }, - { - Name: "WinningPostMaxTasks", - Type: "int", - - Comment: ``, - }, - { - Name: "EnableParkPiece", - Type: "bool", - - Comment: `EnableParkPiece enables the "piece parking" task to run on this node. This task is responsible for fetching -pieces from the network and storing them in the storage subsystem until sectors are sealed. This task is -only applicable when integrating with boost, and should be enabled on nodes which will hold deal data -from boost until sectors containing the related pieces have the TreeD/TreeR constructed. -Note that future Curio implementations will have a separate task type for fetching pieces from the internet.`, - }, - { - Name: "ParkPieceMaxTasks", - Type: "int", - - Comment: ``, - }, - { - Name: "EnableSealSDR", - Type: "bool", - - Comment: `EnableSealSDR enables SDR tasks to run. SDR is the long sequential computation -creating 11 layer files in sector cache directory. - -SDR is the first task in the sealing pipeline. It's inputs are just the hash of the -unsealed data (CommD), sector number, miner id, and the seal proof type. -It's outputs are the 11 layer files in the sector cache directory. - -In lotus-miner this was run as part of PreCommit1.`, - }, - { - Name: "SealSDRMaxTasks", - Type: "int", - - Comment: `The maximum amount of SDR tasks that can run simultaneously. Note that the maximum number of tasks will -also be bounded by resources available on the machine.`, - }, - { - Name: "EnableSealSDRTrees", - Type: "bool", - - Comment: `EnableSealSDRTrees enables the SDR pipeline tree-building task to run. -This task handles encoding of unsealed data into last sdr layer and building -of TreeR, TreeC and TreeD. - -This task runs after SDR -TreeD is first computed with optional input of unsealed data -TreeR is computed from replica, which is first computed as field -addition of the last SDR layer and the bottom layer of TreeD (which is the unsealed data) -TreeC is computed from the 11 SDR layers -The 3 trees will later be used to compute the PoRep proof. - -In case of SyntheticPoRep challenges for PoRep will be pre-generated at this step, and trees and layers -will be dropped. SyntheticPoRep works by pre-generating a very large set of challenges (~30GiB on disk) -then using a small subset of them for the actual PoRep computation. This allows for significant scratch space -saving between PreCommit and PoRep generation at the expense of more computation (generating challenges in this step) - -In lotus-miner this was run as part of PreCommit2 (TreeD was run in PreCommit1). -Note that nodes with SDRTrees enabled will also answer to Finalize tasks, -which just remove unneeded tree data after PoRep is computed.`, - }, - { - Name: "SealSDRTreesMaxTasks", - Type: "int", - - Comment: `The maximum amount of SealSDRTrees tasks that can run simultaneously. Note that the maximum number of tasks will -also be bounded by resources available on the machine.`, - }, - { - Name: "FinalizeMaxTasks", - Type: "int", - - Comment: `FinalizeMaxTasks is the maximum amount of finalize tasks that can run simultaneously. -The finalize task is enabled on all machines which also handle SDRTrees tasks. Finalize ALWAYS runs on whichever -machine holds sector cache files, as it removes unneeded tree data after PoRep is computed. -Finalize will run in parallel with the SubmitCommitMsg task.`, - }, - { - Name: "EnableSendPrecommitMsg", - Type: "bool", - - Comment: `EnableSendPrecommitMsg enables the sending of precommit messages to the chain -from this curio instance. -This runs after SDRTrees and uses the output CommD / CommR (roots of TreeD / TreeR) for the message`, - }, - { - Name: "EnablePoRepProof", - Type: "bool", - - Comment: `EnablePoRepProof enables the computation of the porep proof - -This task runs after interactive-porep seed becomes available, which happens 150 epochs (75min) after the -precommit message lands on chain. This task should run on a machine with a GPU. Vanilla PoRep proofs are -requested from the machine which holds sector cache files which most likely is the machine which ran the SDRTrees -task. - -In lotus-miner this was Commit1 / Commit2`, - }, - { - Name: "PoRepProofMaxTasks", - Type: "int", - - Comment: `The maximum amount of PoRepProof tasks that can run simultaneously. Note that the maximum number of tasks will -also be bounded by resources available on the machine.`, - }, - { - Name: "EnableSendCommitMsg", - Type: "bool", - - Comment: `EnableSendCommitMsg enables the sending of commit messages to the chain -from this curio instance.`, - }, - { - Name: "EnableMoveStorage", - Type: "bool", - - Comment: `EnableMoveStorage enables the move-into-long-term-storage task to run on this curio instance. -This tasks should only be enabled on nodes with long-term storage. - -The MoveStorage task is the last task in the sealing pipeline. It moves the sealed sector data from the -SDRTrees machine into long-term storage. This task runs after the Finalize task.`, - }, - { - Name: "MoveStorageMaxTasks", - Type: "int", - - Comment: `The maximum amount of MoveStorage tasks that can run simultaneously. Note that the maximum number of tasks will -also be bounded by resources available on the machine. It is recommended that this value is set to a number which -uses all available network (or disk) bandwidth on the machine without causing bottlenecks.`, - }, - { - Name: "BoostAdapters", - Type: "[]string", - - Comment: `BoostAdapters is a list of tuples of miner address and port/ip to listen for market (e.g. boost) requests. -This interface is compatible with the lotus-miner RPC, implementing a subset needed for storage market operations. -Strings should be in the format "actor:ip:port". IP cannot be 0.0.0.0. We recommend using a private IP. -Example: "f0123:127.0.0.1:32100". Multiple addresses can be specified. - -When a market node like boost gives Curio's market RPC a deal to placing into a sector, Curio will first store the -deal data in a temporary location "Piece Park" before assigning it to a sector. This requires that at least one -node in the cluster has the EnableParkPiece option enabled and has sufficient scratch space to store the deal data. -This is different from lotus-miner which stored the deal data into an "unsealed" sector as soon as the deal was -received. Deal data in PiecePark is accessed when the sector TreeD and TreeR are computed, but isn't needed for -the initial SDR layers computation. Pieces in PiecePark are removed after all sectors referencing the piece are -sealed. - -To get API info for boost configuration run 'curio market rpc-info' - -NOTE: All deal data will flow through this service, so it should be placed on a machine running boost or on -a machine which handles ParkPiece tasks.`, - }, - { - Name: "EnableWebGui", - Type: "bool", - - Comment: `EnableWebGui enables the web GUI on this curio instance. The UI has minimal local overhead, but it should -only need to be run on a single machine in the cluster.`, - }, - { - Name: "GuiAddress", - Type: "string", - - Comment: `The address that should listen for Web GUI requests.`, - }, - }, "DealmakingConfig": { { Name: "StartEpochSealingBuffer", diff --git a/node/config/types.go b/node/config/types.go index c6c7aaef4..fdda3b84f 100644 --- a/node/config/types.go +++ b/node/config/types.go @@ -60,20 +60,6 @@ type StorageMiner struct { HarmonyDB HarmonyDB } -type CurioConfig struct { - Subsystems CurioSubsystemsConfig - - Fees CurioFees - - // Addresses of wallets per MinerAddress (one of the fields). - Addresses []CurioAddresses - Proving CurioProvingConfig - Ingest CurioIngestConfig - Journal JournalConfig - Apis ApisConfig - Alerting CurioAlerting -} - type ApisConfig struct { // ChainApiInfo is the API endpoint for the Lotus daemon. ChainApiInfo []string @@ -89,140 +75,6 @@ type JournalConfig struct { DisabledEvents string } -type CurioSubsystemsConfig struct { - // EnableWindowPost enables window post to be executed on this curio instance. Each machine in the cluster - // with WindowPoSt enabled will also participate in the window post scheduler. It is possible to have multiple - // machines with WindowPoSt enabled which will provide redundancy, and in case of multiple partitions per deadline, - // will allow for parallel processing of partitions. - // - // It is possible to have instances handling both WindowPoSt and WinningPoSt, which can provide redundancy without - // the need for additional machines. In setups like this it is generally recommended to run - // partitionsPerDeadline+1 machines. - EnableWindowPost bool - WindowPostMaxTasks int - - // EnableWinningPost enables winning post to be executed on this curio instance. - // Each machine in the cluster with WinningPoSt enabled will also participate in the winning post scheduler. - // It is possible to mix machines with WindowPoSt and WinningPoSt enabled, for details see the EnableWindowPost - // documentation. - EnableWinningPost bool - WinningPostMaxTasks int - - // EnableParkPiece enables the "piece parking" task to run on this node. This task is responsible for fetching - // pieces from the network and storing them in the storage subsystem until sectors are sealed. This task is - // only applicable when integrating with boost, and should be enabled on nodes which will hold deal data - // from boost until sectors containing the related pieces have the TreeD/TreeR constructed. - // Note that future Curio implementations will have a separate task type for fetching pieces from the internet. - EnableParkPiece bool - ParkPieceMaxTasks int - - // EnableSealSDR enables SDR tasks to run. SDR is the long sequential computation - // creating 11 layer files in sector cache directory. - // - // SDR is the first task in the sealing pipeline. It's inputs are just the hash of the - // unsealed data (CommD), sector number, miner id, and the seal proof type. - // It's outputs are the 11 layer files in the sector cache directory. - // - // In lotus-miner this was run as part of PreCommit1. - EnableSealSDR bool - - // The maximum amount of SDR tasks that can run simultaneously. Note that the maximum number of tasks will - // also be bounded by resources available on the machine. - SealSDRMaxTasks int - - // EnableSealSDRTrees enables the SDR pipeline tree-building task to run. - // This task handles encoding of unsealed data into last sdr layer and building - // of TreeR, TreeC and TreeD. - // - // This task runs after SDR - // TreeD is first computed with optional input of unsealed data - // TreeR is computed from replica, which is first computed as field - // addition of the last SDR layer and the bottom layer of TreeD (which is the unsealed data) - // TreeC is computed from the 11 SDR layers - // The 3 trees will later be used to compute the PoRep proof. - // - // In case of SyntheticPoRep challenges for PoRep will be pre-generated at this step, and trees and layers - // will be dropped. SyntheticPoRep works by pre-generating a very large set of challenges (~30GiB on disk) - // then using a small subset of them for the actual PoRep computation. This allows for significant scratch space - // saving between PreCommit and PoRep generation at the expense of more computation (generating challenges in this step) - // - // In lotus-miner this was run as part of PreCommit2 (TreeD was run in PreCommit1). - // Note that nodes with SDRTrees enabled will also answer to Finalize tasks, - // which just remove unneeded tree data after PoRep is computed. - EnableSealSDRTrees bool - - // The maximum amount of SealSDRTrees tasks that can run simultaneously. Note that the maximum number of tasks will - // also be bounded by resources available on the machine. - SealSDRTreesMaxTasks int - - // FinalizeMaxTasks is the maximum amount of finalize tasks that can run simultaneously. - // The finalize task is enabled on all machines which also handle SDRTrees tasks. Finalize ALWAYS runs on whichever - // machine holds sector cache files, as it removes unneeded tree data after PoRep is computed. - // Finalize will run in parallel with the SubmitCommitMsg task. - FinalizeMaxTasks int - - // EnableSendPrecommitMsg enables the sending of precommit messages to the chain - // from this curio instance. - // This runs after SDRTrees and uses the output CommD / CommR (roots of TreeD / TreeR) for the message - EnableSendPrecommitMsg bool - - // EnablePoRepProof enables the computation of the porep proof - // - // This task runs after interactive-porep seed becomes available, which happens 150 epochs (75min) after the - // precommit message lands on chain. This task should run on a machine with a GPU. Vanilla PoRep proofs are - // requested from the machine which holds sector cache files which most likely is the machine which ran the SDRTrees - // task. - // - // In lotus-miner this was Commit1 / Commit2 - EnablePoRepProof bool - - // The maximum amount of PoRepProof tasks that can run simultaneously. Note that the maximum number of tasks will - // also be bounded by resources available on the machine. - PoRepProofMaxTasks int - - // EnableSendCommitMsg enables the sending of commit messages to the chain - // from this curio instance. - EnableSendCommitMsg bool - - // EnableMoveStorage enables the move-into-long-term-storage task to run on this curio instance. - // This tasks should only be enabled on nodes with long-term storage. - // - // The MoveStorage task is the last task in the sealing pipeline. It moves the sealed sector data from the - // SDRTrees machine into long-term storage. This task runs after the Finalize task. - EnableMoveStorage bool - - // The maximum amount of MoveStorage tasks that can run simultaneously. Note that the maximum number of tasks will - // also be bounded by resources available on the machine. It is recommended that this value is set to a number which - // uses all available network (or disk) bandwidth on the machine without causing bottlenecks. - MoveStorageMaxTasks int - - // BoostAdapters is a list of tuples of miner address and port/ip to listen for market (e.g. boost) requests. - // This interface is compatible with the lotus-miner RPC, implementing a subset needed for storage market operations. - // Strings should be in the format "actor:ip:port". IP cannot be 0.0.0.0. We recommend using a private IP. - // Example: "f0123:127.0.0.1:32100". Multiple addresses can be specified. - // - // When a market node like boost gives Curio's market RPC a deal to placing into a sector, Curio will first store the - // deal data in a temporary location "Piece Park" before assigning it to a sector. This requires that at least one - // node in the cluster has the EnableParkPiece option enabled and has sufficient scratch space to store the deal data. - // This is different from lotus-miner which stored the deal data into an "unsealed" sector as soon as the deal was - // received. Deal data in PiecePark is accessed when the sector TreeD and TreeR are computed, but isn't needed for - // the initial SDR layers computation. Pieces in PiecePark are removed after all sectors referencing the piece are - // sealed. - // - // To get API info for boost configuration run 'curio market rpc-info' - // - // NOTE: All deal data will flow through this service, so it should be placed on a machine running boost or on - // a machine which handles ParkPiece tasks. - BoostAdapters []string - - // EnableWebGui enables the web GUI on this curio instance. The UI has minimal local overhead, but it should - // only need to be run on a single machine in the cluster. - EnableWebGui bool - - // The address that should listen for Web GUI requests. - GuiAddress string -} - type MinerSubsystemConfig struct { EnableMining bool EnableSealing bool @@ -543,20 +395,6 @@ type MinerFeeConfig struct { MaximizeWindowPoStFeeCap bool } -type CurioFees struct { - DefaultMaxFee types.FIL - MaxPreCommitGasFee types.FIL - MaxCommitGasFee types.FIL - - // maxBatchFee = maxBase + maxPerSector * nSectors - MaxPreCommitBatchGasFee BatchFeeConfig - MaxCommitBatchGasFee BatchFeeConfig - - MaxTerminateGasFee types.FIL - // WindowPoSt is a high-value operation, so the default fee should be high. - MaxWindowPoStGasFee types.FIL - MaxPublishDealsFee types.FIL -} type MinerAddressConfig struct { // Addresses to send PreCommit messages from PreCommitControl []string @@ -575,135 +413,6 @@ type MinerAddressConfig struct { DisableWorkerFallback bool } -type CurioAddresses struct { - // Addresses to send PreCommit messages from - PreCommitControl []string - // Addresses to send Commit messages from - CommitControl []string - TerminateControl []string - - // DisableOwnerFallback disables usage of the owner address for messages - // sent automatically - DisableOwnerFallback bool - // DisableWorkerFallback disables usage of the worker address for messages - // sent automatically, if control addresses are configured. - // A control address that doesn't have enough funds will still be chosen - // over the worker address if this flag is set. - DisableWorkerFallback bool - - // MinerAddresses are the addresses of the miner actors to use for sending messages - MinerAddresses []string -} - -type CurioProvingConfig struct { - // Maximum number of sector checks to run in parallel. (0 = unlimited) - // - // WARNING: Setting this value too high may make the node crash by running out of stack - // WARNING: Setting this value too low may make sector challenge reading much slower, resulting in failed PoSt due - // to late submission. - // - // After changing this option, confirm that the new value works in your setup by invoking - // 'lotus-miner proving compute window-post 0' - ParallelCheckLimit int - - // Maximum amount of time a proving pre-check can take for a sector. If the check times out the sector will be skipped - // - // WARNING: Setting this value too low risks in sectors being skipped even though they are accessible, just reading the - // test challenge took longer than this timeout - // WARNING: Setting this value too high risks missing PoSt deadline in case IO operations related to this sector are - // blocked (e.g. in case of disconnected NFS mount) - SingleCheckTimeout Duration - - // Maximum amount of time a proving pre-check can take for an entire partition. If the check times out, sectors in - // the partition which didn't get checked on time will be skipped - // - // WARNING: Setting this value too low risks in sectors being skipped even though they are accessible, just reading the - // test challenge took longer than this timeout - // WARNING: Setting this value too high risks missing PoSt deadline in case IO operations related to this partition are - // blocked or slow - PartitionCheckTimeout Duration - - // Disable WindowPoSt provable sector readability checks. - // - // In normal operation, when preparing to compute WindowPoSt, lotus-miner will perform a round of reading challenges - // from all sectors to confirm that those sectors can be proven. Challenges read in this process are discarded, as - // we're only interested in checking that sector data can be read. - // - // When using builtin proof computation (no PoSt workers, and DisableBuiltinWindowPoSt is set to false), this process - // can save a lot of time and compute resources in the case that some sectors are not readable - this is caused by - // the builtin logic not skipping snark computation when some sectors need to be skipped. - // - // When using PoSt workers, this process is mostly redundant, with PoSt workers challenges will be read once, and - // if challenges for some sectors aren't readable, those sectors will just get skipped. - // - // Disabling sector pre-checks will slightly reduce IO load when proving sectors, possibly resulting in shorter - // time to produce window PoSt. In setups with good IO capabilities the effect of this option on proving time should - // be negligible. - // - // NOTE: It likely is a bad idea to disable sector pre-checks in setups with no PoSt workers. - // - // NOTE: Even when this option is enabled, recovering sectors will be checked before recovery declaration message is - // sent to the chain - // - // After changing this option, confirm that the new value works in your setup by invoking - // 'lotus-miner proving compute window-post 0' - DisableWDPoStPreChecks bool - - // Maximum number of partitions to prove in a single SubmitWindowPoSt messace. 0 = network limit (3 in nv21) - // - // A single partition may contain up to 2349 32GiB sectors, or 2300 64GiB sectors. - // // - // Note that setting this value lower may result in less efficient gas use - more messages will be sent, - // to prove each deadline, resulting in more total gas use (but each message will have lower gas limit) - // - // Setting this value above the network limit has no effect - MaxPartitionsPerPoStMessage int - - // Maximum number of partitions to declare in a single DeclareFaultsRecovered message. 0 = no limit. - - // In some cases when submitting DeclareFaultsRecovered messages, - // there may be too many recoveries to fit in a BlockGasLimit. - // In those cases it may be necessary to set this value to something low (eg 1); - // Note that setting this value lower may result in less efficient gas use - more messages will be sent than needed, - // resulting in more total gas use (but each message will have lower gas limit) - MaxPartitionsPerRecoveryMessage int - - // Enable single partition per PoSt Message for partitions containing recovery sectors - // - // In cases when submitting PoSt messages which contain recovering sectors, the default network limit may still be - // too high to fit in the block gas limit. In those cases, it becomes useful to only house the single partition - // with recovering sectors in the post message - // - // Note that setting this value lower may result in less efficient gas use - more messages will be sent, - // to prove each deadline, resulting in more total gas use (but each message will have lower gas limit) - SingleRecoveringPartitionPerPostMessage bool -} - -type CurioIngestConfig struct { - // Maximum number of sectors that can be queued waiting for SDR to start processing. - // 0 = unlimited - // Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem. - // The SDR queue includes deals which are in the process of entering the sealing pipeline - size of this queue - // will also impact the maximum number of ParkPiece tasks which can run concurrently. - // - // SDR queue is the first queue in the sealing pipeline, meaning that it should be used as the primary backpressure mechanism. - MaxQueueSDR int - - // Maximum number of sectors that can be queued waiting for SDRTrees to start processing. - // 0 = unlimited - // Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem. - // In case of the trees tasks it is possible that this queue grows more than this limit, the backpressure is only - // applied to sectors entering the pipeline. - MaxQueueTrees int - - // Maximum number of sectors that can be queued waiting for PoRep to start processing. - // 0 = unlimited - // Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem. - // Like with the trees tasks, it is possible that this queue grows more than this limit, the backpressure is only - // applied to sectors entering the pipeline. - MaxQueuePoRep int -} - // API contains configs for API endpoint type API struct { // Binding address for the Lotus API @@ -947,18 +656,3 @@ type FaultReporterConfig struct { // rewards. This address should have adequate funds to cover gas fees. ConsensusFaultReporterAddress string } - -type CurioAlerting struct { - // PagerDutyEventURL is URL for PagerDuty.com Events API v2 URL. Events sent to this API URL are ultimately - // routed to a PagerDuty.com service and processed. - // The default is sufficient for integration with the stock commercial PagerDuty.com company's service. - PagerDutyEventURL string - - // PageDutyIntegrationKey is the integration key for a PagerDuty.com service. You can find this unique service - // identifier in the integration page for the service. - PageDutyIntegrationKey string - - // MinimumWalletBalance is the minimum balance all active wallets. If the balance is below this value, an - // alerts will be triggered for the wallet - MinimumWalletBalance types.FIL -}