Hi Adam,
Â
During one of earlier interactions, you expressed concerns/opinions about using environment variables to pass input and output values between the TOSCA orchestrator and shell scripts:
Â
- Clearly using environment variable for outputs doesnât work. As alternatives, we discussed passing a file descriptor, or an environment variable that specifies a location to which
to write outputs. Have you given any more thought to this?
Yes I considered implementing something like that where the shell scripts could echo outputs to a file descriptor that was set in an environment variable and the orchestrator would read from that file after the script terminated. But I didn't find implementing this was necessary since my orchestrator has TOSCA extensions that lets theÂuser configure the environment variables passed to the shell script or process and also a template which has access to the script's stdout, stderr and returncode. So essentially the user is free to implement any private protocol between the orchestrator and shell script as needed. This is particularly useful if you need to work with pre-existingÂscripts.
Regarding file descriptors, their main benefits compared to a file path are that file descriptors are more secure: easier to avoid potential race conditions and information leaks, and they can point to a private temp file not visible on the file system. They are also more flexible (e.g. they don't require access to a file system, they can point to pipe so they can more easily support streaming, etc.)
- Even for input values, environment variable are not always convenient. What is the standard way for encoding maps, lists, or complex data types so they can be carried in an environment
variable? Iâm curious how your implementation handles this.
Â
My implementation handles this by trying to parse the variable's value as JSON, and if parsing fails,Âtreat it as a string. This approach is easy to implement and handles numbers, lists, and maps pretty much as the user would expect. Â