Technically, we have support for getting environment variables that is not utilized currently.
We can make it possible getting environment variables, e.g. (as one of thoughts) as follows:
- Pass metadata from host to guest through
Inputs (e.g. extend this structure to be able to set env vars).
- On guest, add a way to retrieve metadata and "install" it, potentially with validation (e.g. restrict which environment variables can be set and which cannot).
- In "installation", initialize a once cell for "guest state", which for now will include environment variables and their values.
- In
sys_getenv from airbender-rt/glue access this guest state and read data from there.
Note: if we will be using inputs for passing info from host to guest, it's important to make sure that we don't introduce inconsistencies, e.g. think about the following:
- Probably passing metadata should be opt-in. Maybe we need some kind of HostMetadataBuilder (choose better name) that will have a builder interface which would allow adding more functionality later in a non-breaking way.
- Decoding metadata should be explicit and consistent, e.g. potentially we want clients to read it as an explicit action and "install" (with potential validation, as described above) as another explicit action.
There should be no surprices or magic happening under the hood.
Technically, we have support for getting environment variables that is not utilized currently.
We can make it possible getting environment variables, e.g. (as one of thoughts) as follows:
Inputs(e.g. extend this structure to be able to set env vars).sys_getenvfromairbender-rt/glueaccess this guest state and read data from there.Note: if we will be using inputs for passing info from host to guest, it's important to make sure that we don't introduce inconsistencies, e.g. think about the following:
There should be no surprices or magic happening under the hood.