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

Use custom options of the create client command #2004

Merged
merged 29 commits into from
Apr 4, 2022

Conversation

mzabaluev
Copy link
Contributor

@mzabaluev mzabaluev commented Mar 23, 2022

Closes: #1921

Description

Rework settings passed to build_client_state to make the custom parameters of create client command work.


PR author checklist:

  • Added changelog entry, using unclog.
  • Added tests: integration (for Hermes) or unit/mock tests (for modules).
  • Linked to GitHub issue.
  • Updated code comments and documentation (e.g., docs/).

Reviewer checklist:

  • Reviewed Files changed in the GitHub PR explorer.
  • Manually tested (in case integration/unit/mock tests are absent).

ClientSettings is now realized from CreateOptions and chain
configurations.
@mzabaluev mzabaluev changed the title Mikhail/create client options Use custom options of the create client command Mar 23, 2022
Copy link
Member

@adizere adizere left a comment

Choose a reason for hiding this comment

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

I did some tests and the CLI works as expected when customizing trusting period and trust threshold.

For customizing clock drift, I realize it's not clear to me what the expected behavior should be.

Example:

hermes create client ibc-0 ibc-1 -t 1/2 -p 1200s -d 2s

Do we want 2s to be either:

  • option A: the final clock drift used in this client state? Or

  • option B: do we want to use 2s to compute the client's clock drift (like we used to do here).

In this PR, we implement option B option A. I agree with this. So the CLI above gives

...
trust_level: TrustThreshold {
numerator: 1,
denominator: 2,
},
trusting_period: 1200s,
unbonding_period: 1814400s,
max_clock_drift: 2s,

Note that the max_clock_drift is set to 2s, as I specified in the create command CLI. This means we should update the CLI help command, which is not accurate at the moment, because it says the following:

-d, --clock-drift <CLOCK_DRIFT>
Override the default clock drift specified in the configuration.

With -d we're not exactly overriding the configuration value. Instead, we are providing the exact clock_drift to be used in the created client state.

relayer/src/chain/client.rs Outdated Show resolved Hide resolved
mzabaluev and others added 3 commits March 23, 2022 21:41
Co-authored-by: Adi Seredinschi <adi@informal.systems>
Explain that the value goes directly into the client state parameter.
…stems/ibc-rs into mikhail/create-client-options
@ancazamfir
Copy link
Collaborator

ancazamfir commented Mar 24, 2022

Do we want 2s to be either:

  • option A: the final clock drift used in this client state? Or
  • option B: do we want to use 2s to compute the client's clock drift (like we used to do here).

In this PR, we implement option B.

I think we implement option A, right?

I also agree with A and we should update the help string.

@ancazamfir
Copy link
Collaborator

One other thought is to warn the user if the configured client max_clock_drift is smaller than the destination chain max_block_time. In this case there is a high chance of "header in the future" chain errors.

Make the settings specific to the chain type, in anticipation of
support for non-Cosmos chains.
Change the test framework API to bootstrap ForeignClient and
ForeignClientPair to use the builder pattern.
The client_settings methods are used to override the default client
settings.
@mzabaluev mzabaluev marked this pull request as ready for review March 30, 2022 12:00
@mzabaluev mzabaluev requested a review from adizere March 30, 2022 12:01
}
}

impl BinaryChainTest for ClientDefaultsTest {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it would be clearer to have a BinaryNodeTest for this case, with the foreign clients being created manually with the custom client settings you want. Basically the test should call ForeignClient::new() or ForeignClient::restore() directly, and then call ForeignClient::build_create_client_and_send() with the custom client settings, because this is the actual method we want to test here.

For this particular test, it is more of testing that the test framework is correctly initializing the foreign clients with the wanted settings. We could still leave the test here for testing the correctness of the test framework itself.

I think it is also worth writing some simple tests to demonstrate why we need a SettingsTestOverrides. For example, is having the ability to override the max_clock_drift setting helps us write new integration tests that we couldn't before? If the tests are too complicated to write in this PR, then we should file a new issues to follow up on writing these tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good points, the tests could exercise the API directly indeed rather than deferring it to the framework.

As for ClientSettingsOverride, I think the ability to tweak the pre-created clients could be useful, and it does not get in the way of writing any tests that don't need this feature. The long trait bound lists in the framework code itself could become unwieldy, but they could be made more manageable with helper traits if needed. One thing this override trait cannot address is n-ary tests, but the same problem exists for the other override traits.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, so do you think it is unnecessary to write another test using BinaryNodeTest to test ForeignClient::build_create_client_and_send() directly?

One thing this override trait cannot address is n-ary tests, but the same problem exists for the other override traits.

For the case of ports override, we use nested arrays to provide a matrix of overrides. But I think we can just omit that for now and only add them when it is needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@romac says custom client settings could be useful to test misbehavior detection.

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually I meant writing an additional test to test the function directly. But anyway it's a nit and doesn't matter too much.

Copy link
Member

@adizere adizere left a comment

Choose a reason for hiding this comment

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

I only did a cursory review of the code, looks good, I have no suggestions there, cool work Mikhail esp. with integration test and modular support for capturing client state setting!

The CLI behaves as expected.

Will let @ancazamfir and @soareschen weigh in on the details of the implementation.

/// The parameters are specialized for each supported chain type.
#[derive(Clone, Debug)]
pub enum ClientSettings {
Cosmos(cosmos::client::Settings),
Copy link
Member

Choose a reason for hiding this comment

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

Neat!

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'm not sure if Cosmos or Tendermint is the right name to use here.
AnyClientState uses Tendermint, maybe we should use it here too for consistency?

Copy link
Member

Choose a reason for hiding this comment

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

This is a very good point. Tendermint is more appropriate than Cosmos.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OTOH the module hierarchy under chain uses cosmos. This is a relayer API anyway, so we don't have to be super-diligent.

@adizere
Copy link
Member

adizere commented Mar 31, 2022

Added the "needs guide update" label as it would be worthwhile to document the extended support for -t -d and -p options in the create client guide entry: https://hermes.informal.systems/commands/path-setup/clients.html#create-client

relayer/src/chain/cosmos.rs Outdated Show resolved Hide resolved
Restore the "phase transition" between user-supplied options in
the relayer CLI and client settings in the chain interface.
This gets rid of the ugly must-use method (fill_in_from_chain_configs)
and makes the ForeignClient API easier to use.
@mzabaluev mzabaluev merged commit 1fda889 into master Apr 4, 2022
@mzabaluev mzabaluev deleted the mikhail/create-client-options branch April 4, 2022 11:09
@adizere adizere mentioned this pull request Apr 25, 2022
7 tasks
hu55a1n1 pushed a commit to hu55a1n1/hermes that referenced this pull request Sep 13, 2022
* Rework of CreateParams -> ClientOptions

* Split CreateOptions and ClientSettings

ClientSettings is now realized from CreateOptions and chain
configurations.

* Update docs in relayer/src/chain/client.rs

Co-authored-by: Adi Seredinschi <adi@informal.systems>

* Improve help for --clock-drift

Explain that the value goes directly into the client state parameter.

* Rework ClientSettings

Make the settings specific to the chain type, in anticipation of
support for non-Cosmos chains.

* Builder pattern for foreign client tests

Change the test framework API to bootstrap ForeignClient and
ForeignClientPair to use the builder pattern.
The client_settings methods are used to override the default client
settings.

* Add client setting overrides to the test framework

* Warn when client clock drift exceeds max_block_time

* relayer: Sanitize imports in mod chain
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Client create parameters are ignored
5 participants