Skip to content
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

Implement real vs mock protocol selection #335

Merged
merged 9 commits into from
Feb 3, 2020
Merged

Conversation

Jimbo4350
Copy link
Contributor

@Jimbo4350 Jimbo4350 commented Nov 26, 2019

Implements the NodeProtocolMode type which differentiates whether the node is running a real protocol vs a mock protocol.
Changes:

The cardano-node client is now as follows (with further help for both run and run-mock via cabal exec cardano-node run/run-mock -- --help):

Usage: cardano-node (run | run-mock) [--help]
  Start node of the Cardano blockchain.

Available options:
  --help                   Show this help text

Execute node with a real protocol.
  run                      Execute node with a real protocol.

Execute node with a mock protocol.
  run-mock                 Execute node with a mock protocol.

Relevant: #297, #318, #314

@Jimbo4350 Jimbo4350 changed the title Implement real vs mock protocol selection- Implement real vs mock protocol selection Nov 26, 2019
@Jimbo4350 Jimbo4350 marked this pull request as ready for review November 26, 2019 17:59
@Jimbo4350 Jimbo4350 force-pushed the jordan/mock-vs-real branch 3 times, most recently from deabf69 to 91d099a Compare November 27, 2019 16:03
Copy link
Contributor

@dcoutts dcoutts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few things I don't get yet:

  • the mock protocol mode seems to be being used in more places than I expected, especially scripts
  • how is the specific test/mock protocol selected? In the old CLI there was --bft --praos --mock-praos etc.

Do the scripts still work?

nodeRealProtocolModeParser = subparser
( commandGroup "Execute node with a real protocol."
<> metavar "real-protocol"
<> command "real-protocol"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that the CLI name, like cardano-cli real-protocol --blah --blah? Using "mock-protocol" is fine for the mock one since it makes it clear it's different, but I don't think symmetry justifies making what is really the default one be a name that'll be surprising to users.

Perhaps we want "run" and "run-mock" or something?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the node-cli the protocol is defined in the configuration .yaml file. The cardano-cli uses --real-pbft etc to specific which protocol it's using. I can change it to run and run-mock.

}
]
{
"rProducers": [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"rProducers"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Meant to be short for real producers. Any naming suggestions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to "Producers"

tmux select-pane -t 3
tmux send-keys "cd '${PWD}'; ${CMD} exe:cardano-node $(nodeargs 2 "${ALGO} $(echo -n ${EXTRA})") " C-m
tmux send-keys "cd '${PWD}'; ${CMD} exe:cardano-node mock-protocol $(nodeargs 2 "${ALGO} $(echo -n ${EXTRA})") " C-m
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was it using one of the test protocols before? Which one? How was that specified before?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made an error here, these are using log-config-*.yaml files which use RealPBFT. I associated mock with test, I'll fix it.

#CMD="stack exec --nix cardano-node --"
CMD="cabal new-run exe:cardano-node --"
CMD="cabal new-run exe:cardano-node -- mock-protocol"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this for the testnet? Why is this a mock protocol?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as: #335 (comment)

@@ -20,7 +20,7 @@ ulimit -t $CPU_TIME_LIMIT

date --iso-8601=seconds > STARTTIME

NODE="cabal new-run exe:cardano-node -- "
NODE="cabal new-run exe:cardano-node -- mock-protocol "
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand. This is for the mainnet.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as: #335 (comment)

@Jimbo4350 Jimbo4350 force-pushed the jordan/mock-vs-real branch 2 times, most recently from 61bf2d7 to f02c173 Compare November 29, 2019 13:33
@Jimbo4350
Copy link
Contributor Author

A few things I don't get yet:

  • the mock protocol mode seems to be being used in more places than I expected, especially scripts
  • how is the specific test/mock protocol selected? In the old CLI there was --bft --praos --mock-praos etc.

Do the scripts still work?

The protocols are currently specified in the config .yaml files. I've also updated the scripts to reflect that they are running real protocols 🙂.

@Jimbo4350 Jimbo4350 force-pushed the jordan/mock-vs-real branch 4 times, most recently from 8c7375b to b5bf8dd Compare December 2, 2019 16:25
Copy link
Contributor

@dcoutts dcoutts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far looks fine.

I realise we don't want to load too much into each PR. But my main question is below, about when we plan to differentiate between the config content of the NodeMockCLI vs the NodeRealCLI to reflect what is actually used for each one.

Comment on lines 164 to 166
configYamlFp <- case nodeProtocolMode of
RealProtocolMode (NodeRealCLI _ _ rConfigFp _) -> pure rConfigFp
MockProtocolMode (NodeMockCLI _ _ mConfigFp _) -> pure mConfigFp
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could probably be a separate projection function, e.g. defined along with NodeProtocolMode.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll make the change.

, realTraceOpts :: !TraceOptions
}

data NodeMockCLI = NodeMockCLI
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naming suggestion: perhaps the real ones should get the short names, and the mock ones a "mock" name prefix.

{ unSocket :: FilePath }
deriving Show
data SocketPath = SocketFile FilePath
| SocketDir FilePath
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a TODO or ticket to remove the dir case again once we finish eliminating the node ids?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dcoutts I was under the impression we still needed the NodeIds for the mock protocols and I believe DevOps finds it easier to work with socket dirs. @deepfire can you clarify re: socket dirs?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The mock/test protocols need the node ids for the consensus algorithms. I'm pretty sure devops have said they want simple "do exactly what I tell you" style with files, and not impose any naming convention.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @deepfire wanted the ability to specify a socket dir for scripts. If not I can remove it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can be removed -- but then all the users will have to be updated.

Comment on lines 114 to 116
(GenesisFile genFp)
(DelegationCertFile <$> delCertFp)
(SigningKeyFile <$> sKeyFp)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's an example. I think none of the mock protocols use these 3 options.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed these three from the parser.

Comment on lines 128 to 61
data NodeRealCLI = NodeRealCLI
{ realMscFp :: !MiscellaneousFilepaths
, realNodeAddr :: !NodeAddress
, realConfigFp :: !ConfigYamlFilePath
, realTraceOpts :: !TraceOptions
, validateDB :: !Bool
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When are we planning to introduce differences between the options for the real and mock modes? Many of the options are specific to either real or mock.

For example the (ncProtocol nc) when we run the node is an example where for the real mode the choice is pre-determined, but for the mock more there is a choice of mock/test protocols. So the mock side would have a field for protocol choice that the real side does not have, since there is only one choice for the real side.

Copy link
Contributor Author

@Jimbo4350 Jimbo4350 Dec 2, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the first differentiation would be removing NodeId from the configuration.yaml file and moving that into a command line argument for mock protocols.

Re: (ncProtocol nc): If I understand what you are saying, (ncProtocol nc) can give any of the protocols: https://github.com/input-output-hk/cardano-node/blob/52e6fb4befd5c89e7a3923166358f0f5a829c573/cardano-config/src/Cardano/Config/Types.hs#L407

Some need to be re-named however to reflect that they are actually mock protocols e.g BFT: https://github.com/input-output-hk/cardano-node/blob/04894d0082921ced7f478631add4191af3374af5/cardano-config/src/Cardano/Config/Protocol.hs#L120

I'm not sure if I've answered your concern.

@Jimbo4350 Jimbo4350 force-pushed the jordan/mock-vs-real branch 9 times, most recently from ccb0657 to 8b0525d Compare December 6, 2019 18:07
@Jimbo4350 Jimbo4350 force-pushed the jordan/mock-vs-real branch 5 times, most recently from 41baaf3 to bcecc7f Compare January 24, 2020 18:58
@Jimbo4350 Jimbo4350 mentioned this pull request Jan 27, 2020
1 task
@Jimbo4350 Jimbo4350 force-pushed the jordan/mock-vs-real branch 2 times, most recently from bcf6ab8 to 8229d16 Compare January 27, 2020 14:45
@Jimbo4350
Copy link
Contributor Author

If approved (again) do not merge as I have to merge https://github.com/input-output-hk/iohk-nix/tree/jordan/update-mkEdgeTopology and then re-point sources.json to iohk-nix.

Copy link
Contributor

@dcoutts dcoutts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@Jimbo4350 Jimbo4350 force-pushed the jordan/mock-vs-real branch 3 times, most recently from d2bb9f0 to 490d9ec Compare February 3, 2020 16:09
Update `nix/cardano-node-service.nix`
Update `nix/scripts.nix`
Update `nix/svclib.nix`
@Jimbo4350
Copy link
Contributor Author

bors r+

iohk-bors bot added a commit that referenced this pull request Feb 3, 2020
335: Implement real vs mock protocol selection r=Jimbo4350 a=Jimbo4350

Implements the `NodeProtocolMode` type which differentiates whether the node is running a real protocol vs a mock protocol.
Changes:
- When running a real protocol, the topology comes from a `JSON` file which is decoded to `RealNodeTopology` which specifies the addresses the node intends to connect to.
- `socket-dir` command line argument is changed to `socket-path` i.e you must specify socket paths and not dirs anymore.
- `NodeId` only needs to be specified for mock protocols (https://github.com/input-output-hk/cardano-node/blob/d24cefd7a4fb1afbf13e8e7f7971e22704673f98/cardano-config/src/Cardano/Config/Protocol.hs#L129)

The `cardano-node` client is now as follows (with further help for both `run` and `run-mock` via `cabal exec cardano-node run/run-mock -- --help`):
```
Usage: cardano-node (run | run-mock) [--help]
  Start node of the Cardano blockchain.

Available options:
  --help                   Show this help text

Execute node with a real protocol.
  run                      Execute node with a real protocol.

Execute node with a mock protocol.
  run-mock                 Execute node with a mock protocol.
```
Relevant: #297, #318, #314

Co-authored-by: Jordan Millar <jordan.millar@iohk.io>
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Feb 3, 2020

@iohk-bors iohk-bors bot merged commit caf342f into master Feb 3, 2020
@iohk-bors iohk-bors bot deleted the jordan/mock-vs-real branch February 3, 2020 17:50
@mrBliss
Copy link
Contributor

mrBliss commented Feb 11, 2020

I just noticed the changes to Cardano.Node.Run.handleSimpleNode in 59f66cc#diff-6f98f460a187cbfae2f479b840dc7ae4: please can we not copy-paste that much code? So much duplication now! I don't want to have to update everything twice. I see the code already diverging in master (only formatting though).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority medium issues/PRs that SHOULD be addressed. This should be done for the release, but acceptable if it doesn
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants