vat upgrade should put vatParameters in an option bag #5345
Assignees
Labels
Milestone
Comments
warner
added a commit
that referenced
this issue
May 13, 2022
Previously, the parent vat did `E(adminFacet).upgrade(vatParameters)`
Now it does `E(adminFacet).upgrade(bundleCap, { vatParameters })`
This matches the way `vatParameters` are passed to the original
`createVat()` call.
All other options are rejected.
This changes the `adminFacet` API, but internally continues to send
`vatParameters` in their own argument to the underlying device
nodes. If/when we send actual options, we'll need to decide whether to
change the shape of the device node API by converting `vatParameters`
into `options`, or just add additional arguments.
closes #5345
warner
added a commit
that referenced
this issue
May 26, 2022
Previously, the parent vat did `E(adminFacet).upgrade(vatParameters)`
Now it does `E(adminFacet).upgrade(bundleCap, { vatParameters })`
This matches the way `vatParameters` are passed to the original
`createVat()` call.
All other options are rejected.
This changes the `adminFacet` API, but internally continues to send
`vatParameters` in their own argument to the underlying device
nodes. If/when we send actual options, we'll need to decide whether to
change the shape of the device node API by converting `vatParameters`
into `options`, or just add additional arguments.
closes #5345
warner
added a commit
that referenced
this issue
Jun 1, 2022
Previously, the parent vat did `E(adminFacet).upgrade(vatParameters)`
Now it does `E(adminFacet).upgrade(bundleCap, { vatParameters })`
This matches the way `vatParameters` are passed to the original
`createVat()` call.
All other options are rejected. The `options` argument itself is
optional.
This changes the `adminFacet` API, but internally continues to send
`vatParameters` in their own argument to the underlying device
nodes. If/when we send actual options, we'll need to decide whether to
change the shape of the device node API by converting `vatParameters`
into `options`, or just add additional arguments.
closes #5345
warner
added a commit
that referenced
this issue
Jun 1, 2022
Previously, the parent vat did `E(adminFacet).upgrade(vatParameters)`
Now it does `E(adminFacet).upgrade(bundleCap, { vatParameters })`
This matches the way `vatParameters` are passed to the original
`createVat()` call.
All other options are rejected. The `options` argument itself is
optional.
This changes the `adminFacet` API, but internally continues to send
`vatParameters` in their own argument to the underlying device
nodes. If/when we send actual options, we'll need to decide whether to
change the shape of the device node API by converting `vatParameters`
into `options`, or just add additional arguments.
closes #5345
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the Problem Being Solved?
Vats are created with
vatAdminService~.createVat(bundleCap, options), whereoptionsincludes{ vatParameters }and others.Vats are upgraded with
adminFacet~.upgrade(newBundleCap, newVatParameters).We should change this to be
upgrade(newBundleCap, { vatParameters }), for parallelism with the original creation API, and to start an options bag for later.Note that we don't currently have any other options. Many of the options available during initial creation are not changable by upgrade (e.g. the
managerTypeis fixed at creation time). I don't currently think any of those other options are worth changing during upgrade, or it would be difficult to allow them to be changed. ButvatParametersis how we'll give a new contract bundlecap to ZCF, so it's important to be replaceable.Description of the Design
Change the function signature.
Security Considerations
None
Test Plan
Update the existing unit tests
The text was updated successfully, but these errors were encountered: