Create example of app.go for users, test in real configuration, fix IBC-Go test suite to handle it

[mpoke]

• branch ibc-go and make necessary changes
• fork out the ibc-go test framework and make necessary changes
  • postponed
• create non-minimal example app.go for consumer
• create non-minimal example app.go for provider
• create minimal example app.go for consumer
  • fixed by remove unnecessary parts of app.go in consumer and provider #98
• create minimal example app.go for provider
  • fixed by remove unnecessary parts of app.go in consumer and provider #98
• make sure the apps are tested in the unit tests using ibc-go/testing
• test the two apps using the docker integration tests
• add comment in app.go addressing the order of EndBlock (see Order of EndBlock() #51 (comment))
  • moved to remove unnecessary parts of app.go in consumer and provider #98

[jtremback]

In the short term, there will be 3 different users of our app.go example.

• First, the Cosmos Hub team at IG will need to install the CCV provider module into the Cosmos Hub's app.go.
• Then we, and the Ethernal team will need to install the CCV consumer module into the CosmWasm consumer chain.
• Also, teams with custom consumer chains will need to install the CCV consumer module as well.

I think it will be important have separate app.go files for provider and consumer chains. This is because the functioning of the consumer chain depends on certain modules being disabled. Even if we fixed this somehow, we would still want separate app.gos because the Hub will not want to pull in the consumer module and increase the attack surface.

For this to happen some changes will need to be made to the IBC-Go test suite to allow it to test two chains with separate app.gos.

As I just discussed with @danwt I think the time has come for us to fork the IBC-Go test framework into it's own repo. Dealing with a test framework that needs frequent modifications but also is bundled with one of our core dependencies is a pain.

Alternately, we could just keep modifying the IBC-Go test framework in our forked IBC-Go repo, but I'm not sure that has a lot of benefits.

[danwt]

fork the IBC-Go test framework into it's own repo.

I think it's a good idea. The ultimate goal would be to have a general tool for testing ibc apps across heterogeneous chains so the name could be something like 'ibc-tester'. It must be built for our needs first though, without premature generalization.

[danwt]

This issue is relevant for understanding current ibc-go testing limitations

• Feat: Enable multiple validators and valset update ibc-go#918

[danwt]

From speaking with @jtremback we decided this has high priority. I will tackle this first.

[danwt]

With some small slightly hacky changes (1,2) the ibc-go testing can support multiple app.go's.

Now I'm wondering if I need to create completely separate /app packages or I can somehow share the contents of /app between an app_parent.go and an app_child.go

Figured it out

[danwt]

This issue is quite related to

• Restructure Interchain Security repo for release #77

[danwt]

Two PRs solve the basics of this issue

• Pass through an AppIniter func to be able to launch chains with different apps informalsystems/ibc-go#1 - enables multiple app.go's in testing framework
• Support different app.go's for consumer and provider #84 - uses multiple app.go's in interchain security

Now there are two copies of the app.go that contains both provider and consumer logic so I should additionally strip the provider-only logic from the consumer and the consumer-only logic from the provider. That might fall better under either of

• Create minimum runnable consumer chain #59
• Restructure Interchain Security repo for release #77

Additionally I need to make sure the docker integration tests work with the new apps

[danwt]

Hi @alexanderbez. We spoke on slack. Here's my understanding

The ultimate goal is to have two separate app's that people can use as a basis. The provider can be like gaia and the consumer should be minimal but with democracy and/or cosmwasm. As I understand democracy is needed to enable cosmwasm in practice. Ethernal are working on cosmwasm and they are having problems with conflicting sdk versions ect. There is some uncertainty about the best way to structure the repo(s) to make all this possible.

The PR #84 doesn't do much. It simply splits the apps and updates the tests (in-memory and integration) to use two different apps.

[danwt]

Can we close this?