[Feature] Container snapshots and restore

[kripper]

What problem or use case are you trying to solve?

Somestimes OH modifications to the workspace are not as desired.
I noticed OH can undo file changes, but apparently only on single files and only 1 step back (?).
When we say "revert the changes", it's also not clear until which point we want OH to revert.
Having a feature to revert until a previous user input message would be nice.

Describe the UX of the solution you'd like

It would be nice to be able to edit any previous user message (just like with ChatGPT, Gemini, etc) and have OH automatically rollback the workspace to that point.

Do you have thoughts on the technical implementation?

• Btrfs snapshots using a loop device
• LVM snapshots
• docker commit? Maybe too slow...
• CRIU...too much.

[neubig]

Hey @kripper , thanks for the feedback! We have thought about this, but it's not a trivial implementation. We can track this and hopefully come up with something.

Another option would be to push to github if a repo is available.

CC @BBischof who commented something similar.

[kripper]

What are your thoughts about a docker commit of the sandbox?

[neubig]

I think it's definitely a possibility! There may be concerns about whether this is efficient enough (with respect to time and space).

[kripper]

Docker should provide some snapshoting mechanism, but it has a design philosophy problem (they want them to stay ephemeral).
I was checking CRIU, but it's too much (memory spanshots included).

[kripper]

Maybe LVM snapshots on the OH container/host?

[kripper]

I tested btrfs snapshots succesfully and will be working on this feature.
Please comment.

[neubig]

Thanks! I'm honestly not familiar enough with these options to comment on the technical approach, but I think if it's not too hard to prototype it'd be great to get a poc of this.

[diwu-sf]

Have you consider doing the simplest thing possible?
cp -r -a ...

Btrfs, loop device, lvm, those all require kernel privileges and support by the kernel.
They won't work on the SaaS deployments with GKE and EKS.

[zxh3]

Have you consider doing the simplest thing possible? cp -r -a ...

Btrfs, loop device, lvm, those all require kernel privileges and support by the kernel. They won't work on the SaaS deployments with GKE and EKS.

Also looking for a solution for revert, but cp does not work universally. Things like global package install won't work w/o some nasty hacks.

[kripper]

I tested it using a loop device running inside a container in WSL2, which means it will work on any setup.

[kripper]

What are your use cases?
Should OH have a skill to undo things that didn't work?
Or should the checkpoint restore operation only be performed by the user?

[enyst]

We could start with the user IMO, the feature would be immediately testable and useful.

[neubig]

I agree, we should have this be user triggered at first.

[kripper]

Can be tested here: #6441

Can we ask OH to add a restore button on the front end and to store the snapshot ID returned by create_snapshot() together with the user message?