AaronKutch
commented
1 year ago I just pushed two more commits that added a README in case you want to run my custom test harness for yourself
Closed AaronKutch closed 1 year ago
AaronKutch
commented
1 year ago I just pushed two more commits that added a README in case you want to run my custom test harness for yourself
AaronKutch
commented
1 year ago I found that when moving from v1.2.0 to v1.2.0-multiden that the chain-id problem and assign-consensus-keys problem doesn't happen, but the hermes error does. I later figured out that I should probably add "provider_reward_denoms": [] to the proposal when the multiden patch is present, but adding it doesn't seem to change anything. edit: v1.1.0-multiden also has same properties
AaronKutch
commented
1 year ago I figured out the hermes error, needed to add the line delete(blockedAddrs, authtypes.NewModuleAddress(providertypes.ConsumerRewardsPool).String()) (although there should be something better than a nullptr exception and some good guesses on what I'm missing vs Gaia in order to guide me in the right direction).
shaspitz
commented
1 year ago Hey @AaronKutch, thanks for the info. Note this repo hasn't been in production until recently, consequently there may be state migrations required between some of the versions you're mentioning. In particular v1.2.0-multiden is the current canonical version for consumers, and v1.1.0-multiden for providers. The v2 release branch is not production ready just yet, and v2 will require state migrations if your chain/testnet is upgrading from one version to another. Could I get more context on the enviroment that you're trying to use ICS? Are you just using the consumer module? Testnet? docker? etc. Thanks
AaronKutch
commented
1 year ago We decided to go with v1.1.0-multiden since it has been tested on Gaia, although I will periodically test new versions locally to foresee any issues. I didn't know a different version was canonical for consumers, so I will switch to v1.2.0-multiden for our first upcoming consumer. The context is that we were planning to have an unusual number of modules and sidecars for our chain. Our main worry was that a single failing component will bring down the entire chain, among other problems with the previous approach. When ICS came out, we decided upon turning our main chain into a relatively minimal and stable producer, and have each major component on its own consumer chain. We are trying to launch a testnet by next week.
shaspitz
commented
1 year ago Yea for now use the multiden versions mentioned, and when v2.0.0 comes out, that'd be the preferred versions to use. There will be instructions re state migrations. Following the v2 release, we plan to split out the semver for consumer and provider so that they'll each have their own release cycle. It'll be a lot more strait forward
shaspitz
commented
1 year ago Hey @AaronKutch I'm going to close this issue as we've released v2.0.0. Please open a new issue with a specific problem and a way to reproduce if you're still running into migration related challenges.
When trying to test out v2.0.0-rc1 (e.x. 58a0b1a on https://github.com/onomyprotocol/onomy/tree/provider_v2.0.0-rc1_upgrade), I got much different behavior than from v1.2.0. First, it seems that even after configuring the chain-id with
cosmovisor run config chain-id interchain-security-c, whencosmovisor run init --overwriteis executed it produces agenesis.jsonwith a chain-id in the formattest-chain-[random]instead of what I configured it to be. Is this just some property of the release candidate similar to how git tags affects the version?After manually correcting the chain-id, when running
tx provider assign-consensus-keyin the preparation for querying the consumer genesis, I getWhich makes no sense. The whole purpose of this command is to assign keys, why would it need to require keys to already have been assigned?
Edit: I fixed the hermes error, see below comment If I skip
assign-consensus-key, then later after successfully opening the transfer channel, when attempting to open a producer-consumer channel via hermes it relays this error back to me. I'm guessing its because no consensus keys have been assigned and that the case is not being handled gracefully.The logs of both producer and consumer runners are both indicating normal block production and channel state updates, no warnings given. It shows both the transfer and producer-consumer channel capabilities being claimed, the only difference being that the third "channel state updated" message is not being reached for connection-1 since hermes is failing at that point.