Hi Chris,
Responses inline below:
On Sun, Oct 4, 2020 at 5:22 PM Chris Lauwers <
lauwers@ubicity.com> wrote:
> 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.
Thanks,
>
>
>
> Chris
>
>
>
>
>
>
>