Add option in pebble exec to inherit environment variables from caller's environment

[averma-canonical]

Request to add an option in pebble exec command to inherit environment variables from the caller's environment, much like the preserve-env option in sudo.

The use case is for pebble to execute a one-shot command as a non-root user inheriting all environment variables the rock has defined for the root user.

[niemeyer]

Unlike sudo, the thing being started is not a plain shell or a plain command, but rather a program that will carry its own environment and configuration, and in general will have an expectation of it being preserved. Blindly fiddling with this environment is likely to result in unexpected behavior. For that kind of reason, even in applications such as ssh the client environment's won't be sent over transparently.

Can you provide some further details about what you intent to do with it? Maybe there is some alternative.

[benhoyt]

See also the planned feature for exec (and exec-type health checks) we've called "context", which would allow you to run commands in the context of another service, or of Pebble itself:

• Add "context" option for pebble exec and exec health checks #159 -- feature issue
• Discussion: feature to allow passing environment variables from Pebble's own environment to services #125 -- previous discussion

Would --context=pebble, or similar, work for you? As Gustavo mentioned, it would also be good to know more about your specific use case.

[averma-canonical]

The use case is Apache Spark (short-lived) batch jobs where the rock image gets spawned as driver pod as well as executor pods (driver / executor is just an execution mode argument for the rock). They do their bit and the pods are torn down.

1. No daemons involved within the rock, hence the "pebble exec" option is being used.
2. Since "pebble enter exec" is still in the works, we had to work around it by having a custom entrypoint script pebble-start.sh which does "pebble run --hold" followed by "pebble exec". Due to this design, pebble is not running as PID 1.
3. To run the driver/executor programs as non-root, we had to lump all Spark-relevant environment variables (defined for root user in the rock), together for the non-root user as a long list of --env options to the "pebble exec command".

This issue pertains to 3. where some facility to inherit all environment variables from caller's environment (root) can be made available for the pebble exec command's target environment (non-root).

I believe PID != 1 issue in 2. will be addressed with the "pebble enter exec" command which is being developed, so did not raise that separately.

[benhoyt]

@averma-canonical Thanks for that description. It seems to me that the addition of --context=pebble (or --context=- or whatever syntax we give it) would solve your problem, right? That would mean run with the same environment variables as Pebble was started with.

[averma-canonical]

Thanks @benhoyt. Yes that is exactly what we need.

[benhoyt]

Thanks. In that case I'll close this issue in favour of the existing #159.