-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
[Epic]: Rosetta migration to standalone repo #16276
Comments
we can fix this in the repo quite easily, just dont import rosetta into the sdk and then import a released version. Im not 100% convinced it needs to be moved yet. The question i still have is will rosetta depend on the sdk or would it use grpc reflection to get all the needed data? you mentioned some plugin system but still unclear what is happening with rosetta. Mainly asking because there is always the chance that rosetta will fall on the sdk teams shoulder and I dont want to endup in a world where we delete lots of work to get it to its simplest state. |
The fix was easy but it took us some time, we rolled back some changes so rosetta can depend only on latest cosmos release. The changes were made (probably by mistake) when doing some refactors. We would like to avoid that in the future. Rosetta depends on Cosmos-sdk for the decoders and interfaces. We were working on the plugin functionability that allows users to extend Rosetta to use it on their zones (you can see we have some example for cosmos-hub and osmosis zones). Eventough the best solution would be to use gRPC reflection as you mentioned (and as hubl does), after trying to use hubl against multiple zones we came into the conclusion that we depend not only on other zones to use the latest release of Cosmos-sdk but to implement one service which is not mandatory to do so. The idea behind this Epic is to make Rosetta easier to work with and maintain, following the release cycle and making sure that each release of cosmos will have a working release of Rosetta. About the new features, the objective is to maka rosetta cosmos-sdk implementation extendable to other zones |
The thing is rosetta is getting tagged from release branches, the latest version of rosetta has been tagged from release/v0.47.x (https://pkg.go.dev/cosmossdk.io/tools/rosetta?tab=versions / https://github.com/cosmos/cosmos-sdk/blob/tools/rosetta/v0.2.1/tools/rosetta/go.mod). |
Yes, this is technically true and will also allow you to get what you're looking for. By removing any usage of rosetta in the SDK and pinning the SDK version in rosetta's go.mod, this should allow you to get what you want. |
You both have good points @julienrbrt @alexanderbez, if we work on fixes over Rosetta, our users wont be able to access them until we launch a new release of cosmos. Which in a way slows down adoption and forces people to create forks and so on. |
Yes, I'm not against spinning Rosetta out! I'm actually in favor of it. Just agreeing with @tac0turtle is all. But yah, you have my support on that. |
Thank you @alexanderbez ! Hi @tac0turtle ! what do you think? what can we do from our side to move this forward? |
it seems there is a proposal to use plugins, has reflection been explored in order to remove the dependence on cosmos-sdk. Looking at the plugin system, would be interested in understanding why hashicorp plugins wasnt considered since we use this in the sdk and it would be good to align all things if the plugin system is picked. Mentioned in the call, is there any chance a quick adr/rfc can be written? |
Hi @tac0turtle thanks for sharing your concerns! Yes, we considered using the same reflection mechanism as HUBL tool does, since the different zones need to implement a specific (optional) service in order for us to register their interfaces + they need to upgrade to v0.47.x at least (most of the ones we checked are running on v0.45.x) we decided for now to run the plugin approach. We want to migrate to reflection eventually, but we believe it might take some time until it is worth it. I have reviewed the hashicorp plugins system, our approach is the same: Compile your code, then register it (by adding it to the folder). By the docs and code I have been reading, I believe hashicorp system is designed with another purpose in mind (I might be wrong), thus I don't think registering interfaces would be a good use case for it. Let us write the adr/rfc and share it with the team so we can discuss it 🚀 |
Hey @tac0turtle, do you want the ADR about the epic, for the plugin system or for both things? |
Cleanup efforts: #17112 |
Summary
The goal is to move Rosetta tool under
cosmos-sdk/tools
folder to a separated repo, in order to have a cleaner well structure maintenance and management of Rosetta efforts.Problem Definition
While working on features and improvements over Rosetta. Our team have experienced some common issues related to dependencies and versioning due to the nested Rosetta project. In order to guarantee that the cosmos implementation of Rosetta always work and since it relies on Cosmos-sdk releases to work. We propose to detach it from the root repo.
Here are a few arguments pro decoupling Rosetta tool from cosmos-sdk
Work Breakdown
In order to detach this project we need to rollback some changes so Rosetta can depend only on the latest cosmos-sdk release. Which at tis time is v0.47.x. See issue #16273
The text was updated successfully, but these errors were encountered: