-
Notifications
You must be signed in to change notification settings - Fork 208
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
chore(pp-upgrade): test functionality after provisionPool and bank upgrade #10419
base: master
Are you sure you want to change the base?
Conversation
Deploying agoric-sdk with Cloudflare Pages
|
e375cde
to
51a631d
Compare
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.
I suspect that it would be a good idea to convert makeBridgeProvisionTool
from a Far object to an Exo, but I'm not positive. I've asked for advice and will let you know what I hear.
vm.CoreProposalStepForModules( | ||
"@agoric/builders/scripts/vats/upgrade-provisionPool.js", | ||
), | ||
vm.CoreProposalStepForModules( | ||
"@agoric/builders/scripts/vats/upgrade-bank.js", | ||
), |
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.
Please put this in a separate section with a comment saying it's for upgrade 19 as is done in #10418.
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.
Duplicating these files is the wrong solution. AIUI, the problem is that when docker runs the proposals, it only mounts a single proposal's directory at a time. I've talked this over with @turadg, and I'd like to try using symbolic links to manage this.
Please add a lib
directory in a3p-integration
next to proposals
, and put a canonical copy of the file there. Then make each of the proposals that want to import all or some of sync-tools
include a symbolic link to that file, so the tests can import ./sync-tools.js
. Do the same with errors.js.
I haven't verified how this will work with github, but I'd like to try the approach out here.
PROVISIONING_POOL_ADDR, | ||
ambientAuthority, | ||
{ denom: 'uist', value: istBalanceBeforeLemonsSent + 500000 }, | ||
{ errorMessage: 'Provision pool not bale swap USDC_axl for IST.' }, |
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.
{ errorMessage: 'Provision pool not bale swap USDC_axl for IST.' }, | |
{ errorMessage: 'Provision pool not able to swap USDC_axl for IST.' }, |
{ maxRetries: 5, retryIntervalMs: 1000, log: console.log, setTimeout }, | ||
); | ||
|
||
test(`upgrade provision pool`, async t => { |
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.
Please check the incarnation #s of both vats. I think the tests would pass if the upgrade didn't take place since there's no change in behavior to detect.
The response I got was "yes, convert it to an Exo", but it appears that this object may be one of those discussed in #8849, which may mean we need a clearer story on upgrading the bootstrap vat (V1) before we can proceed to upgrade provisionPool. You can work on converting it to an Exo I need to have more design discussions with the kernel team about the impact. The concern seems to be about whether auto-provisioning will continue to work. The links mentioned were
|
#10425 tracks this now. From your comment I understand the path for this PR to land;
Could you please confirm? @Chris-Hibbert |
Let's pursue 10425. If we can write tests that show the bootstrap vat doesn't break, and we can continue to provision new wallets, I don't think we have to be able to upgrade vat-bootstrap before upgrading provisionPool. |
closes: #10395
Description
As mentioned in #8158, we need the ability to restart or replace all vats. This PR focuses on the vats v28-provisionPool and v14-bank. The goal is to make sure after upgrading both of those vats, v28-provisionPool functionality keeps working. We pay special attention to #8722 and #8724 during the tests as those issues were identified as potential problems against v28-provisionPool upgrade.
Security Considerations
v28-provisionPool and v14-bank are critical vats for the system when it comes to onboarding new users and keeping track of ERTP representations of user assets. Reviewers, please highlight the slightest risk you see.
Scaling Considerations
v28-provisionPool vat has a linear relationship with the number of users entering the Agoric system. So it is pretty important it keeps working. Reviewers, please highlight the slightest risk you see.
Documentation Considerations
None.
Testing Considerations
During the testing, we focused on
provisionPoolAddress
' cosmos level balances as our source of truth. The reasoning behind this is; if the IST balance of theprovisionPoolAddress
it can only meanIn our test we send two anchor assets;
Upgrade Considerations
Both v28-provisionPool and v14-bank are staged upgrades in
upgrade.go