-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor network/consensus versioning #2358
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mrBliss
commented
Jul 3, 2020
ouroboros-consensus/ouroboros-consensus-test-infra/src/Test/ThreadNet/Network.hs
Show resolved
Hide resolved
ouroboros-consensus/ouroboros-consensus-test-infra/src/Test/ThreadNet/Util/NodeToNodeVersion.hs
Show resolved
Hide resolved
ouroboros-consensus/ouroboros-consensus-mock/src/Ouroboros/Consensus/Mock/Node.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/test-consensus/Test/Consensus/HardFork/Combinator.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/test-consensus/Test/Consensus/MiniProtocol/ChainSync/Client.hs
Outdated
Show resolved
Hide resolved
edsko
approved these changes
Jul 3, 2020
Good to clarify this logic, much cleaner. |
Fixes #2309. Previously, we had a list of supported `BlockNodeToNodeVersion`s and a method to translate them to a `NodeToNodeVersion`. This meant that there were two layers of "support": (1) include the version in `BlockNodeToNodeVersion` and (2) return a non-`error` for it in the translation function. Replace these methods by a map from `NodeToNodeVersion` to `BlockNodeToNodeVersion`. Similarly for `NodeToClient`. An important insight is that not each network version requires a consensus-side block version. For example, enabling the `LocalStateQuery` `NodeToClient` protocol requires a new network version, but no block version, as the serialisation format doesn't change. A new block version is only needed when the serialisation changes, so not when protocols get added/removed or the protocol messages are added/removed. This means we don't need separate Byron (nor Cardano) versions for `NodeToClientV_2`, as the serialisation format didn't change, so remove these redundant versions and map `NodeToClientV_2` to `ByronNodeToClientVersion1`. The `mostRecentSupportedNodeToNode` method was only used for the ThreadNet tests to make sure we were testing the most recent version. Remove this method in favour of randomly picking a supported version in the tests. The `Test.ThreadNet.Util.NodeToNodeVersion` was added to aid in picking a version. * Rewrite `foldMapVersions` and `combineVersions` to work for any `Foldable` instead of a `NonEmpty`, as we now use a `Map` instead of a `NonEmpty` for the supported versions. * Rewrite `Cardano.Client.Subscription` to take a `CodecConfig` + `NetworkMagic` instead of an entire `TopLevelConfig`. Producing a `TopLevelConfig` is a lot of work for clients. The whole point of introducing the `CodecConfig` was to make it easier for clients.
mrBliss
force-pushed
the
mrBliss/versioning
branch
from
July 3, 2020 14:51
0a18b81
to
9e26bb1
Compare
bors merge |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #2309.
Previously, we had a list of supported
BlockNodeToNodeVersion
s and a methodto translate them to a
NodeToNodeVersion
. This meant that there were twolayers of "support": (1) include the version in
BlockNodeToNodeVersion
and (2) return a non-
error
for it in the translation function.Replace these methods by a map from
NodeToNodeVersion
toBlockNodeToNodeVersion
. Similarly forNodeToClient
. An important insightis that not each network version requires a consensus-side block version. For
example, enabling the
LocalStateQuery
NodeToClient
protocol requires a newnetwork version, but no block version, as the serialisation format doesn't
change. A new block version is only needed when the serialisation changes, so
not when protocols get added/removed or the protocol messages are
added/removed.
This means we don't need separate Byron (nor Cardano) versions for
NodeToClientV_2
, as the serialisation format didn't change, so remove theseredundant versions and map
NodeToClientV_2
toByronNodeToClientVersion1
.The
mostRecentSupportedNodeToNode
method was only used for the ThreadNettests to make sure we were testing the most recent version. Remove this method
in favour of randomly picking a supported version in the tests. The
Test.ThreadNet.Util.NodeToNodeVersion
was added to aid in picking a version.Rewrite
foldMapVersions
andcombineVersions
to work for anyFoldable
instead of a
NonEmpty
, as we now use aMap
instead of aNonEmpty
forthe supported versions.
Rewrite
Cardano.Client.Subscription
to take aCodecConfig
+NetworkMagic
instead of an entireTopLevelConfig
. Producing aTopLevelConfig
is a lot of work for clients. The whole point ofintroducing the
CodecConfig
was to make it easier for clients.