[HIP] Hyperfile

[danbugs]

This PR adds a HIP for Hyperfile—a TOML configuration file for sandbox configuration and run options.

The goal is to enable host applications built with Hyperlight to be configurable in a non-programmatic way, allowing users to modify microVM settings without directly altering the host code.

You can view the rendered file here.

[ludfjig]

Let's make sure we put every kv in the toml under a table such as [memory] or [runtimeoptinos] to make it forward compatible in case we need to add more fields. I also think we should avoid the name "override" in the fields. Btw, this is probably a good time as well to introduce a builder to UninitializedSandbox, and maybe even change the UninitializedSandbox::new api to be more ergonomic.

[dblnz]

There are two aspects that would need clarifying:

1. How do we treat the case of an older or newer Hyperfile than Hyperlight is being used?
   Example: I am using a Hyperfile that I took from a colleague but it matches a different version of Hyperlight than the one I have. The might not have some fields defined or has additional ones that are no longer valid.
   Should we define some kind of versioning?

2. Is this meant to accommodate multiple configurations or is it used for setting defaults?
   Example: An user has multiple types of sandboxes, how are their configurations chosen?
   Do we add something like a special section for each type of configuration so that the user can mention which one to use, or do we use the Hyperfile for default values?

[marosset]

Have you considered being able to specify multiple different named sandbox configurations in the same file that can be referenced by name when creating the sandboxes?

I can see a use case for wanting to specify different configurations.

This would work similar to how runtime classes work in containerd.

[marosset]

If we do this I imagine one of the entries would be a default one which would be used if no named sandbox configuration is used.

[ludfjig]

What about just doing this in separate files? config1.toml and config2.toml. It would simplify parsing alot, especially if we use the same struct for the config value itself, AND serde toml deserialization. And then you could do something like Config::FromFile(...) on the one you want to use.

[devigned]

+1 to the proposal. Nice work with the structure and content.

I'm curious to see where @marosset's comment leads. I haven't fully thought through it, but I think I'm in favor a default and additional named configurations.

[simongdavies]

Would you see this as the host's responsibility to specify/resolve where these files are at runtime? We could possibly determine the default for a Sandbox via a well known environment variable , however if the host wanted to provide different types of Sandbox with different configurations for each type it would need to specify how this is done , I don't think that is something that can be done in Hyperlight itself, regardless of if this is done in single files or with named configurations in a single file.

[simongdavies]

We should consider how the config file can be used by solutions built on top of hyperlight, e.g. hyperlight-wasm has its own builder and slightly modified configuration, solutions such as this may want to hide/add/restrict configuration items.