Comment 4 for bug 1812519

Here some findings.

- First of all, I'm using a libvirt/qemu environment behind a proxy (not the most friendly setup, but good for finding corner cases..).

- I tried with VirtualBox as the wiki says on an environment with direct access to internet and everything worked.

- I tested two scenarios with the following results:

Using a custom no_proxy
=======================

- In my libvirt/qemu environment I did the following:

Edit the /etc/resolv.conf
Edit /etc/environment

http_proxy=<my-proxy-ip>
https_proxy=<my-proxy-ip>
no_proxy=no_proxy=localhost,127.0.0.1,192.168.206.2,172.16.0.0/16,10.96.0.0/12
# Here 192.168.206.2 was reported as non-reachable in the puppet.log, so I added into the no_proxy.

Edit same proxy settings on docker proxy configuration.

In these conditions is where the openstack service list fails, as reported originally in this bug.

Using a simple no_proxy=127.0.0.1
=================================

Same steps as above with the only difference of using no_proxy=127.0.0.1

In this case config_controller --kubernetes was able to finish with no errors, however it cannot continue due to this error:

controller-0:~$ . /etc/platform/openrc
Openstack Admin credentials can only be loaded from the active controller.

Summary
=======

- My libvirt/qemu setup works on terms of having internet connectivity, I can curl internet hosts and run docker pull manually. So I don't think this could be caused by not using Virtualbox.

- Changes on no_proxy caused different behavior. I've seen in the past some Golang Rest API behave weird living behind a proxy, I had to specify a specific no_proxy to get it work. I'm wondering if this configuration needs a specific no_proxy.