[Avocado-devel] [RFC] Environment Variables

[Cleber Rosa]

On 05/25/2016 05:31 AM, Amador Pahim wrote:
> Hi folks,
>
> We have requests to handle the environment variables that we can set to
> the tests. This is the RFC in that regard, with a summary of the ideas
> already exposed in the original request and some additional planning.
>
> The original request is here:
> https://trello.com/c/Ddcly0oG/312-mechanism-to-provide-environment-variables-to-tests-run-on-a-virtual-machine-remote
>
>
> Motivation
> ==========
> Avocado tests are executed in a fork process or even in a remote
> machine. Regardless the fact that Avocado is hard coded to set some
> environment variables, they are for internal consumption and user is not
> allowed to control/configure its behavior.

You mean this:

http://avocado-framework.readthedocs.io/en/latest/WritingTests.html#environment-variables-for-simple-tests

Right? Basically, the fact that Avocado sets some of the job/test state 
as environment variables, that can be used by SIMPLE tests.

> The motivation is the request to provide users an interface to set
> and/or keep environment variables for test consumption.
>
> Use cases
> =========
> 1) Use the command line or the config file to set the environment
> variables in tests processes environment; access those variables from
> inside the test.
> 2) Copy from current environment some environment variable(s) to the
> tests processes environment; access those variables from inside the test.
>
> Proposal
> ========
> - To create a command line option, under the `run` command, to set
> environment variables that will be available in tests environment process:
>
>  $ avocado run --test-env='FOO=BAR,FOO1=BAR1' passtest.py
>

I can relate to this use case...

> - To create an option in config file with a dictionary of environment
> variables to set in test process environment. It can be used as a
> replacement or complement to the command line option (with lower priority):
>
>  [tests.env]
>  test_env_vars = {'FOO': 'BAR', 'FOO1': 'BAR1'}
>

... while putting those in a config file does not seem like something 
one would do.

In all cases, and more explicitly in the config file example, this is 
only really necessary if/when the environment variable to pass to the 
test actually harms Avocado (considering a local execution, that is, in 
a forked process).

So, if Avocado and the test, share the use of environment variables by 
the same name, then this is a must.  Also in the case of execution in 
other "runners", such as remote/vm, this can be quite valuable.

> - Create an option in config file with a list of environment variable
> names to copy from avocado main process environment to the test process
> environment (similar to env_keep in the /etc/sudoers file):
>
>  [tests.env]
>  env_keep = ['FOO', 'FOO1', 'FOO2']
>
>

Right, this makes sense. But it also brings the point that we may 
actually change the default behavior of keeping environment variables 
from Avocado in the tests' process.  That is, they would get a much 
cleaner environment by default.  While this sounds cleaner, it may break 
a lot of expectations.

> For every configuration entry point, the setting have to be respected in
> local and remote executions.
>
> Drawbacks
> =========
>
> While setting an environment variable, user will be able to change the
> behavior of a test and probably the behavior of Avocado itself. Maybe
> even the OS behavior as well. We should:
> - Warn users about the danger when using such options.

I fail to see where an environment variable, to be set by Avocado in the 
test process, can or should impact Avocado itself.  If it does, then 
we'd probably be doing something wrong.  I'm not sure we need warnings 
that exceed documenting the intended behavior.

> - Protect Avocado environment variables from overwriting.

About protecting the Avocado's own environment variables: agreed.

>
> Looking forward to read your comments.
>

Overall, this is definitely welcome.  Let's discuss possible 
implementation issues, such as remote/vm support, because it wouldn't be 
nice to introduce something like this with too many caveats.

Cheers,
- Cleber.

> Best Regards,
> --
> Amador Pahim
>
> _______________________________________________
> Avocado-devel mailing list
> Avocado-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/avocado-devel

-- 
Cleber Rosa
[ Sr Software Engineer - Virtualization Team - Red Hat ]
[ Avocado Test Framework - avocado-framework.github.io ]