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

Add support for multiple chain types in the configuration #2228

Merged
merged 9 commits into from
Jun 6, 2022

Conversation

romac
Copy link
Member

@romac romac commented May 20, 2022

Closes: #2240

Description

See the proposal on the linked issue.


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).

@romac romac changed the title Add support for multiple chain types Add support for multiple chain types in the configuration May 24, 2022
@romac romac marked this pull request as ready for review May 25, 2022 10:34
Copy link
Collaborator

@ancazamfir ancazamfir left a comment

Choose a reason for hiding this comment

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

Looks great!!! thanks @romac !!

opts: &UpgradePlanOptions,
) -> Result<TxHash, UpgradeChainError> {
let upgrade_height = dst_chain
.query_chain_latest_height()
.query_latest_height() // FIXME(romac): Use query_chain_latest_height once added to ChainHandle
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this going to be fixed with #2185?
A lot of the code in this function is Cosmos/Tendermint specific and should be moved in the Cosmos chain impl (when the fixme is fixed)

Copy link
Member

Choose a reason for hiding this comment

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

I agree, we should tackle this with issue 2185!

Copy link
Member Author

Choose a reason for hiding this comment

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

I can also issue the right call here and add the appropriate method to the handle or would you rather we do this in a follow-up PR?

Copy link
Collaborator

Choose a reason for hiding this comment

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

let's do it in a follow up PR

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>
@ancazamfir
Copy link
Collaborator

Can you also add some comment in config.toml and maybe show the default value:

type = 'CosmosSdk'

@adizere
Copy link
Member

adizere commented Jun 1, 2022

Can you also add some comment in config.toml and maybe show the default value:

type = 'CosmosSdk'

I'm wondering if we should document this chain type feature already in config.toml (and release it with v1), since it's rather experimental.

@ancazamfir
Copy link
Collaborator

ancazamfir commented Jun 1, 2022

Can you also add some comment in config.toml and maybe show the default value:

type = 'CosmosSdk'

I'm wondering if we should document this chain type feature already in config.toml (and release it with v1), since it's rather experimental.

@romac had the same comment offline. I am ok either way. I expect this to be used when other chain types will be supported, e.g. substrate. Not sure at what stage substrate integration is now, was wondering if it would be useful for them to upstream these changes.

@adizere
Copy link
Member

adizere commented Jun 2, 2022

Not sure at what stage substrate integration is now, was wondering if it would be useful for them to upstream these changes.

Good point! Another use-case for the chain type feature is integration with basecoin-rs.

From what I can tell, we're signalling the changes here via (doc)comments and the public API here
https://github.com/informalsystems/ibc-rs/blob/22652ee2aea75cd559aedd151813dbadadd4048b/relayer/src/chain.rs#L17

Not sure how to highlight this API better for substrate or other relayer developers, so that they can find & use it with ease, but as a first approach this looks good to me! If this proves to be too obscure, then I agree we should highlight it in config.toml.

@mzabaluev
Copy link
Contributor

mzabaluev commented Jun 2, 2022

Should we choose the chain type naming convention while we are at it?

"CosmosSdk" (CamelCase) vs. "cosmos-sdk" (kebab-case)

The reason for the latter is, other chain types would often have a one word name, e.g. "substrate", so capitalization of those would look annoying. Think of all those wasteful Shift keypresses.

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.

Looks good, great work Romain!

Pinging @plafer here because the present PR with #2226 will likely conflict, so be aware of the order of merging.

opts: &UpgradePlanOptions,
) -> Result<TxHash, UpgradeChainError> {
let upgrade_height = dst_chain
.query_chain_latest_height()
.query_latest_height() // FIXME(romac): Use query_chain_latest_height once added to ChainHandle
Copy link
Member

Choose a reason for hiding this comment

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

I agree, we should tackle this with issue 2185!

@mzabaluev
Copy link
Contributor

On the third hand, deserialization of the chain type could just be case-insensitive. It should be if this format is also used in CLI, because 1) CLI users on Unix traditionally hate using upper case unless necessary; 2) CLI users on Windows are used to parameters being case-insensitive.

@romac
Copy link
Member Author

romac commented Jun 2, 2022

On the third hand, deserialization of the chain type could just be case-insensitive.

Agreed. I'll see if I can make it both case insensitive and ignore dashes as well.

@romac
Copy link
Member Author

romac commented Jun 2, 2022

On the third hand, deserialization of the chain type could just be case-insensitive.

Agreed. I'll see if I can make it both case insensitive and ignore dashes as well.

Done here: 111f3f0

@adizere adizere merged commit 08b7f98 into master Jun 6, 2022
@adizere adizere deleted the romac/chain-type branch June 6, 2022 07:47
hu55a1n1 pushed a commit to hu55a1n1/hermes that referenced this pull request Sep 13, 2022
…stems#2228)

* Move `ChainEndpoint` trait into its own module

* Add support for multiple chain types

* Add changelog entry

* Remove `type` entry from the default config

* Update relayer-cli/src/cli_utils.rs

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>

* Ignore case and dashes when deserializing `ChainType`

* Fix test

Co-authored-by: Anca Zamfir <ancazamfir@users.noreply.github.com>
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.

Add support for multiple chain types in the configuration
4 participants