-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
one binary, multiple networks #8158
Conversation
WIP. This will make it easier to change parameters, allowing the same binary to be used on multiple networks. This removes the const, and in their place we access through getters. I've submitted a similar proof-of-concept PR in the past and there was some consternation about removing the const's -- open to other ideas. The justification for doing this is to ease operations. We want to be able to easily manage applications that should operate on multiple lotus networks without building and managing multiple binaries/images.
|
I think this is a good first pass at this, nothing jump out at me in regard to setting up or managing networks. I think we should discuss this with @arajasek. |
This allows you to switch networks with the same binary. There are lots of of reasons it would be good to have a binary that can switch networks, particularly, this makes it easier to operate multiple netowrks with the same packages, docker images, etc. Additionally, this adds the ability to specify a network definition file aside from the built-in file. Allowing external network definitions will help build new netowrks on the fly with custom parameters. Currently, this is configured using only environment variables -- I'm not really stuck on this design. I considered re-writing this as a dependency injection, and could be convinced that this would be a better choice. The current design takes previously constant values and instead exports them as getters only, so they cannot be easily changed at runtime. |
woo this looks cool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conflicts/tests need fixing, but this looks really good
och := build.UpgradeClausHeight | ||
build.UpgradeClausHeight = 0 | ||
t.Cleanup(func() { build.UpgradeClausHeight = och }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably can just drop this entire test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a pretty big changes and will require communication.
This PR doesn't touch the Makefile
. However, a lot of the targets are no longer needed and should be removed (all the network builds).
The BuildType + version string should also be addressed.
Lines 8 to 37 in 97b92cd
const ( | |
BuildDefault = 0 | |
BuildMainnet = 0x1 | |
Build2k = 0x2 | |
BuildDebug = 0x3 | |
BuildCalibnet = 0x4 | |
BuildInteropnet = 0x5 | |
BuildButterflynet = 0x7 | |
) | |
func BuildTypeString() string { | |
switch BuildType { | |
case BuildDefault: | |
return "" | |
case BuildMainnet: | |
return "+mainnet" | |
case Build2k: | |
return "+2k" | |
case BuildDebug: | |
return "+debug" | |
case BuildCalibnet: | |
return "+calibnet" | |
case BuildInteropnet: | |
return "+interopnet" | |
case BuildButterflynet: | |
return "+butterflynet" | |
default: | |
return "+huh?" | |
} | |
} |
It would probably be good to keep this version reporting, but make it defined by the LOTUS_NETWORK
/ LOTUS_NETWORK_DEFINITION_FILE
. This will allow people to ask the daemon what network it's talking too, we shouldn't remove this piece of information from users. It's an important bit to gather when users fill out issues.
BuildType |= BuildDebug | ||
} | ||
|
||
// NOTE: Also includes settings from params_2k |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deleting this file breaks make debug
, and no longer does anything. We need to keep the functionality that this file brings.
- Disabling PoSt
- Adding the
+debug
to the version string (this is done by theBuildType |= BuildDebug
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oo, good point.
I was hoping debug networks could be a runtime rather than build time decision. But there are some things that aren't ready for that, and I don't really want to make this PR any bigger than it already is.
I've added a params_debug back in. It sets the SlashablePowerDelay, Insecure PoSt, and sets the "BuildType" to debug.
Codecov Report
@@ Coverage Diff @@
## master #8158 +/- ##
==========================================
- Coverage 40.86% 40.86% -0.01%
==========================================
Files 686 686
Lines 75710 75784 +74
==========================================
+ Hits 30939 30966 +27
- Misses 39445 39466 +21
- Partials 5326 5352 +26
|
Updated the version string so it includes the network name. It also occurs to me that anyone could create a network that matches a well-known built-in network, so I included a hash of the genesis there as well. |
we will need to rethink bundle loading for nv16 with this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can land this if we get the backwards compatibility working
Makefile
Outdated
2k: GOFLAGS+=-tags=2k | ||
2k: build-devnets | ||
|
||
calibnet: GOFLAGS+=-tags=calibnet | ||
calibnet: build-devnets | ||
|
||
butterflynet: GOFLAGS+=-tags=butterflynet | ||
butterflynet: build-devnets | ||
|
||
interopnet: GOFLAGS+=-tags=interopnet | ||
interopnet: build-devnets |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to keep those for compat for now - just changing the default network in the binary.
Can we delay until after m1 ships, so that we figure out the bundling strategy? |
How is this going to affect #9625? |
It would no longer be required. |
If somebody else wants this, it is probably better to start from scratch given the long list of conflicts, and how outdated this PR is by now. Closing for now. |
Related Issues
Proposed Changes
Allow the same binary to be used across multiple networks.
Additionally, parameters can be overridden by environment variables.
Additional Info
Checklist
Before you mark the PR ready for review, please make sure that:
<PR type>: <area>: <change being made>
fix: mempool: Introduce a cache for valid signatures
PR type
: fix, feat, INTERFACE BREAKING CHANGE, CONSENSUS BREAKING, build, chore, ci, docs,perf, refactor, revert, style, testarea
: api, chain, state, vm, data transfer, market, mempool, message, block production, multisig, networking, paychan, proving, sealing, wallet, deps