-
Notifications
You must be signed in to change notification settings - Fork 352
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
Scripts for Gaiad network with full-mesh IBC connections #898
Conversation
This is so great! Starting playing with this today but got stuck. Probably something silly but after running
Is this a local configuration thing? |
You need to upgrade your Docker CLI to v1.0.14 or later. (Relevant issue here.) This version was released only a month ago, so most probably everyone will need to upgrade. The Alternatively, if you just want a quick workaround, replace the |
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 really great. Went through this but I'm still playing with it. We can probably merge with the upgrade 0.3.0 and then follow up with issues.
# But if hermes was not run locally, we're going to overcome the issue of not having a --home parameter | ||
ln -s $(pwd)/.hermes $HOME/.hermes || echo "$HOME/.hermes is already set, make sure you link it to .hermes here if you run things locally" | ||
|
||
EXPECTED_HERMES_VERSION=0.2.0 |
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.
Can we update this to 0.3.0?
# Run in a subfolder, not in your $HOME (safeguard against accidental .gaia-deletions) | ||
test "$HOME" != "$(pwd)" | ||
|
||
EXPECTED_GAIAD_VERSION=4.2.1 |
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 wonderful! Looking forward to trying it out!
I'd love to be able to spin up a mesh with chains using different versions of gaia to test IBC and relayer compatibility between them. Testing that a gaia v4 chain can interact with gaia v5 using the same relayer binary
Another wishlist item is using non-gaia docker images, so chains could test out their docker image before upgrading on mainnet, but I think it might be best to let non-gaia chains copy the script and replace its relevant info rather than maintaining scripts for several chains
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.
Thanks for the feedback! There were a lot of good points from the IBC-rs team about this, including non-gaia docker images. I'm not sure yet how we move forward because I find the current configuration fairly inflexible. We have another tool in the works that is much more flexible for developer work and allows you to choose your binaries on a per-node basis. (Issue #902 .)
So, we might continue expanding the configuration here or maybe we end up merging the two tools. But I'll definitely keep this in mind.
Small trick right now: you can do
make config-files
vi docker-compose.gaiad.yml
make network-up setup-relay
and edit the gaiad images that will be used before they are started.
I propose we close this PR without merging. Here's the alternative I have in mind: in PR #928 I propose a different tool that I feel is more beneficial for the users. Here's a quick comparison: full-mesh-tool:
Disadvantages:
Disadvantages:
Question: is docker a hard requirement for people? Would the |
I think there are two use cases that come to mind (at least from my wishlist):
I think 1) is the immediate priority (and more useful for developers of this repo) and #928 looks like a good approach for this based on the trade offs listed above. Usage of this feature might inform use cases for 2) I think 2) is something we definitely will need to eventually solve and this pr is some good investigation into this problem. Based on some recent discussion on this topic, we determined that this level of testing was a little ahead of where we are now (although never to early to start discussion). We want a solution that supports multiple IBC implementations, relayers, and chains. It needs to be language agnostic and ideally driven by MBT testing. Docker seems like a natural fit here to provide stability. Interaction directly with docker from a user standpoint should be very limited. Interacting with this set of testing should be more along the lines of running a command with various parameters set My interest in 2) stems from wanting to kick off a set of simulations before doing a final ibc-go release to ensure compatibility between chains running an older ibc-go version and the newer ibc-go version (including ensuring that a relayer functions between both) I'll try to document all the testing I do before our next release to inform what features should be supported Documenting any testing I do on this discussion thread |
Note: the latest update to the The docker setup auto-generated here is interesting for some cases but as the immediate priority is dev testing, I'll close this issue with the remark that we can revisit it later and expand on it as integration testing, acceptance testing and end-to-end testing becomes more focused. |
Partial solution to #897
Description
A set of scripts with documentation to create an interconnected set of blockchain networks on a local machine using docker.
Start with the README!
For contributor use:
docs/
) and code comments.Files changed
in the Github PR explorer.