There’s been a fair amount of talk around canister migration, and I understand this feature is still a ways away.
However, now that we have canister snapshots, I’m curious if it might be simple/simpler to use those snapshots to migrate a canister’s wasm and state to a different canister on a different subnet.
Note: This intermediate solution would allow me to migrate the contents of the canister but to a different/new canister id. I understand the importance of keeping the canister id the same in other migration scenarios.
Say for example that I have a transaction history canister that keeps a record of all transactions. I want to migrate this canister to a different subnet for one of the following reasons:
I want this canister to now be on the same subnet as another canister to take advantage of reduced inter-canister latency or to use composite query calls.
The current subnet that it is on is experiencing latency and I wish to migrate to a less crowded subnet
Would restoring a canister from snapshot onto a different/new canister id, potentially on a different subnet be an easy or difficult engineering task to accomplish?
Ideally, then some of this work could then be reused for the full canister migration use case (preserving the canister id).
Canister snapshots are cool ,particularly as a means to hedge against potential data loss during canister upgrade .
But i really don’s see them as a means to canister migration unless a change is made at that would allow for large data movement between subnets or perhaps subnet splitting
In order to use canister snapshots in the way you describe, you’d also need the ability to download the snapshot and then upload it again – which is also not possible right now. Alternatively, some other option on the protocol level that can move state around from one subnet to another but that could become more complex. In addition, as you already mentioned the ability to load a snapshot onto a different canister id would be needed.
The amount of work for the above is not too difficult necessarily but we do need to plan the resources for it, also based on the demand. Fwiw, an effort has been kickstarted internally to look into a possible design for canister migration so I imagine some of this would be covered there.
This option would suffice! It would also be a fantastic way to test out new features and canister upgrades locally/in integration tests against realistic on-chain canister state.
Download the snapshot
Deploy the snapshot locally
Test out the upgrade
Run tests on the upgraded snapshot
So to solve the issue described in the topic thread, then you’d just need the same ability to do #2 but on mainnet.
Downloading and uploading snapshots is something that was planned to happen as an extension to the current MVP of canister snapshots. Again it’s mostly a matter of prioritization against other work.
So, if you say that the issue described in this topic would be sufficiently solved by having this ability, how about the importance/urgency of loading a snapshot onto another canister id?
That’s what I’m referring to as solving the issue in being able to both download the state and then upload that same snapshot to any canister id that I am a controller of. Without being able to upload the snapshot to an arbitrary canister id on a different subnet this wouldn’t work as well - but in that case I might just manually go ahead with adding endpoints and a data migration.
I’d expect uploading a snapshot to an different canister id to essentially wipe whatever was previously in that canister when uploading the snapshot, and could this could be done multiple times with as many different canister ids as desired. The tricky part would be being able to do this for larger snapshots, and probably involve some chunking logic. I’d be curious just how feasible this would be for a canister with 10s to 100s of GB of state.
This is basically why we left this out as an extension as it would need to be figured out. We can certainly engineer a solution but it’s not as straightforward and needs some thinking.
How long might it take to perform a snapshot download/upload for canister of size:
You can probably extrapolate given the current IC limitations. Specifically, what’s the important bit here is the size limit of requests/responses. That’s 2MiB now so that should give you a way to calculate how long it’d take to upload or download some state.
It’s possible I think that you could even make some requests in parallel which could help speed things up a bit more as you would be uploading chunk by chunk (maybe the same for downloading). The API is still under design but once we have something on the interface spec, maybe that would give you a better idea of what be possible.
Does it make any difference if the downloaded/uploaded snapshot has data in stable vs. heap memory?
No, the total is important. The two are indistinguishable for the system as they’re both essentially blobs you download/upload.
- but in that case I might just manually go ahead with adding endpoints and a data migration.