feat: Add sandbox integration

[dragosgheorghioiu]

No description provided.

[jedevc]

Can you update the description with info on how to run the plugin? Also probably worth looking at https://linear.app/unikraft/issue/TOOL-1319/publish-plugins-images.

[jedevc]

Because we're not using the evaluator things in mvdan.sh, it means that things like volumes mounted > out don't work. Also echo $(volumes mounted) won't work, because it's not present in the shell.

If we really don't want to use the evaluator (and want to directly rely on the host's shell), we need to be clear that these are special commands (some sort of prefix, maybe /, like /volumes mounted)?

[dragosgheorghioiu]

the builtins are documented in the help menu but i can make the fact clear that they cannot run on the sandbox directly

maybe some different syntax highlighting for them can also be a plus

[jedevc]

Indeed, but we should be very clear that they are evaluated differently - different syntaxing is a plus, but also additional syntax to really clarify is useful too. Otherwise, users will attempt to use it like I showed, and will be surprised that it doesn't.

[dragosgheorghioiu]

maybe a special "builtin mode" that is triggered by keybind where you can only run builtins
maybe that would be clear enough for the user

[jedevc]

That's also possible. I've seen some cool stuff before where you type something like ! at the beginning of the line, and the prompt changes - but if you backspace, it goes back to the normal prompt. So it's not like a "mode", it's more like a nice display on top of a prefix.

[dragosgheorghioiu]

not sure how to handle cd and export because they technically run locally

for example:
:cd - runs locally and changes the cwd for the following commands
cd - runs on the instance itself and effects only the current command

[jedevc]

oh 🙁 hm, cd then needs to be different. although, argh, this works really weirdly for things like echo foo; cd bar; pwd.

make an exception for cd for now, but as I've mentioned before, we need to do some real shell parsing to properly solve this.

[dragosgheorghioiu]

but then it would be really unclear where the cd is being run

[jedevc]

Yeah, exactly, but that's the problem with this approach.

IMO, just pick something that feels sensible for now, this is experimental anyways — we should make sure there's a log message on all sandbox commands warning that this is experimental. I'm confident these problems are solvable, but the core problem is that we are trying to handle some builtins ourselves, and sending others to the remote sh — this split responsibility is what's causing all this. The solution is to remove the split:

• Either we use mvdan/sh and have all the commands + builtins evaluated directly by us.
• Or we open a login shell on the remote, and just stream all our commands there, so there's only one command running, then there's cd persistence there (but we then lose the ability to know the working directory at all, and a bunch of other shiny things).

[dragosgheorghioiu]

maybe the "different mode" idea would work better for now

[nderjung]

I wonder if we can derive the default --plugin <name> for sandbox from https://github.com/unikraft-cloud/openapi/blob/prod-staging/plugins/sandbox.yaml#L838-L839 (and image)

[dragosgheorghioiu]

done

i think the sdk exports only the name for now, i can also add suport for it to export the image as well
happy to add it as it may also enable stuff like --sandbox or --plugin sandbox in the create instance command