stub out the Orchestrator API #9207
Assignees
Labels
enhancement
New feature or request
Comments
This was referenced Apr 8, 2024
Merged
mergify bot
added a commit
that referenced
this issue
Apr 24, 2024
step towards: #9207 ## Description Adapt https://github.com/agoric-labs/orchestration-api-spec/ into agoric-sdk Once approved, I'll clean up the commits. Once landed, I'll archive the other repo, pointing people to `@agoric/orchestration` in this codebase. ### Security Considerations <!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls? --> ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations <!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? --> ### Upgrade Considerations <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
mergify bot
added a commit
that referenced
this issue
May 2, 2024
…`makeAccount` (#9312) <!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺ v ✰ Thanks for creating a PR! ✰ ☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --> <!-- Most PRs should close a specific Issue. All PRs should at least reference one or more Issues. Edit and/or delete the following lines as appropriate (note: you don't need both `refs` and `closes` for the same one): --> closes: #XXXX refs: #9207 ## Description <!-- Add a description of the changes that this PR introduces and the files that are the most critical to review. --> - removes `cancelToken` logic from `.undelegate()` - renames `createAccount` to `makeAccount` for `orchestration` and `localchain` ([Method Naming Structure](https://docs.agoric.com/guides/ertp/#method-naming-structure)) - `make<Foo>()`: Creates a new Foo object and returns only that object. - `create<Foo>()`: Creates a new Foo, but doesn't return it. - renames `getChainAddress` -> `getAddress` on `orchestration` ### Security Considerations <!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls? --> ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations <!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? --> ### Upgrade Considerations <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
Merged
mergify bot
added a commit
that referenced
this issue
May 15, 2024
closes: #9207 ## Description Refactoring the API types and perhaps implementation to satsisfy: - a types module specifying the public chain-agnostic interface for Orchestration - it must not expose Cosmos SDK types - it should not change - a types module for the IBC subclass of the public interface ### Security Considerations <!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls? --> ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations <!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? --> ### Upgrade Considerations <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
mergify bot
added a commit
that referenced
this issue
May 21, 2024
closes: #9207 ## Description While working on #9376 I needed some tests to check how the pieces fit together. None of them actually make progress on #9063 that that branch points to so I'm submitting them under this other PR. The goal of this PR is just to provide unit tests and some cleanup of the app code. It still has a lot of fake stuff. ### Security Considerations <!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls? --> ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations <!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? --> ### Upgrade Considerations never yet deployed
mergify bot
added a commit
that referenced
this issue
May 23, 2024
refs: #9063 refs: #9207 ## Description As part of #9063 I'm trying to improve the testing situation. One challenge is faking the bridges. This PR factors out some test utils, with the eventual goal of providing fixtures in each test for the bridge comms. Along the way I realized that one of the tests had the wrong bridge, and that we could have avoided that if the scoped bridges were typed by their bridgeId. So this also does that. @michaelfig I'd like your take on this. ### Security Considerations <!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls? --> ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations <!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? --> ### Upgrade Considerations <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
mergify bot
added a commit
that referenced
this issue
May 24, 2024
refs: #9207 ## Description Working balances through `makeFakeBankBridge`. ### Security Considerations none, test code ### Scaling Considerations none, test code ### Documentation Considerations Contract devs may want to use these utilities eventually. I think they're too early to document yet. ### Testing Considerations per se ### Upgrade Considerations none, test code
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the Problem Being Solved?
https://github.com/agoric-labs/orchestration-api-spec/ describes a spec for an Orchestrator helper object. We should validate it by implementing it in agoric-sdk. Not all the pieces are available yet but we can fill out much of it to ensure it fits.
Description of the Design
Make the Exo class with tests. Whatever doesn't yet work, assert that they throw.
Include JSDoc and Markdown documentation so partners can see how they would use it, so that they can give feedback.
Security Considerations
Scaling Considerations
Test Plan
Upgrade Considerations
The text was updated successfully, but these errors were encountered: