-
Notifications
You must be signed in to change notification settings - Fork 329
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
Conversation
ClientSettings is now realized from CreateOptions and chain configurations.
create client
command
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 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.
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
I think we implement option A, right? I also agree with A and we should update the help string. |
One other thought is to warn the user if the configured client |
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.
Use the IBC TrustThreshold type throughout. Override a warning.
} | ||
} | ||
|
||
impl BinaryChainTest for ClientDefaultsTest { |
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 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.
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.
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.
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.
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.
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.
@romac says custom client settings could be useful to test misbehavior detection.
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.
Actually I meant writing an additional test to test the function directly. But anyway it's a nit and doesn't matter too much.
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 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.
relayer/src/chain/client.rs
Outdated
/// The parameters are specialized for each supported chain type. | ||
#[derive(Clone, Debug)] | ||
pub enum ClientSettings { | ||
Cosmos(cosmos::client::Settings), |
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.
Neat!
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'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?
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 very good point. Tendermint
is more appropriate than Cosmos
.
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.
OTOH the module hierarchy under chain
uses cosmos
. This is a relayer API anyway, so we don't have to be super-diligent.
Added the "needs guide update" label as it would be worthwhile to document the extended support for |
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.
* 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
Closes: #1921
Description
Rework settings passed to
build_client_state
to make the custom parameters ofcreate client
command work.PR author checklist:
unclog
.docs/
).Reviewer checklist:
Files changed
in the GitHub PR explorer.