Open Stack

Hi JF,

We have some clear documentation for this case here 
https://docs.openstack.org/openstack-ansible/latest/user/limited-connectivity/index.html 
and a discussion of the pros and cons of making system-wide proxy 
configuration.

Once the deployment reaches a certain size it is necessary to use 
transient "deployment_environment_variables" instead of persistent 
"global_environment_variables" to manage no_proxy, both in terms of the 
length of the no_proxy environment variable but also the need to manage 
the contents of that variable across all hosts / containers and running 
services for any changes made to the control plane.

 From experience I can say that it is much much easier to selectively 
enable the use of a proxy during ansible tasks with 
deployment_environment_variables than it is to prevent the use of global 
proxy configuration through no_proxy in the very large number of cases 
that you do not want it (basically the whole runtime of your openstack 
services, loadbalancer, .....).

Regarding the addition of an extra script in /etc/profile.d, I would not 
be in favor of adding this as we already have a very reliable way to 
deploy behind an http proxy using deployment_environment_variables. 
There is great benefit in not leaving any "residual" proxy configuration 
on the hosts or containers.

Hopefully this is helpful,
Jonathan.

On 07/12/2022 11:44, Taltavull Jean-François wrote:
> Hello,
>
> The 'lxc_container_create' role appends the content of the 'global_environment_variables' OSA variable to '/etc/environment', which is used by the library 'libpam'.
>
> On Ubuntu 20.04 and 'libpam-runtime' library version 1.3.1, this works fine unless one of the environment variables content size exceeds 1024 char. In this case, the variable content is truncated. In our OpenStack deployment, this is the variable 'no_proxy' that overflows.
>
> This limit has been raised to 8192 with 'libpam-runtime'  version 1.4 but there is no backport available in Ubuntu 20.04 repositories.
>
> So what would you think of the following workaround: instead of using '/etc/environment' to store the global variables, the role would create a shell script in '/etc/profile.d' thus avoiding the variable truncation issue related to the 'libpam' library ?
>
> This works on Ubuntu, Debian and CentOS hosts and containers.
>
> Cheers,
> JF
>
>