[juju-2.0-beta15] during the bootstrap stage the no-proxy config is ignored
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Expired
|
High
|
Unassigned |
Bug Description
trying to bootstrap (with openstack provider) using a proxy for http(s) and assigning keystone's IP to the no-proxy config key, because the proxy can't reach it, the bootstrap process fails with the following error:
2016-08-22 15:47:39 DEBUG juju.provider.
caused by: authentication failed
The specific command line used is:
juju-2.0 bootstrap \
--config image-stream=
--config image-metadata-url=http://
--config apt-http-proxy=http://
--config apt-https-proxy=http://
--config no-proxy=
--config use-default-
--config https-proxy=http://
--config http-proxy=http://
--config network=
--debug --verbose --show-log \
--keep-broken \
$OS_TENANT_NAME stsstack
In the squid logs is possible to verify how to the bootstrap process is trying to reach keystone through it:
471880785.960 10684 10.5.154.160 TCP_TUNNEL/200 20802033 CONNECT streams.
1471880799.535 12425 10.5.154.160 TCP_TUNNEL/200 6528372 CONNECT streams.
1471880859.077 59369 10.5.154.160 TCP_MISS/504 3964 POST http://
The full log can found at: http://
no longer affects: | juju-core |
Changed in juju: | |
status: | New → Triaged |
importance: | Undecided → High |
milestone: | none → 2.0-beta17 |
Changed in juju: | |
milestone: | 2.0-beta17 → 2.0-beta18 |
Changed in juju: | |
milestone: | 2.0-beta18 → 2.0-beta19 |
Changed in juju: | |
milestone: | 2.0-beta19 → 2.0-rc1 |
Changed in juju: | |
milestone: | 2.0-rc1 → 2.0-rc2 |
Changed in juju: | |
milestone: | 2.0-rc2 → 2.0.1 |
Changed in juju: | |
milestone: | 2.0.1 → none |
--config no-proxy= "10.5.* ,192.168. *,10.230. *" is not valid no_proxy syntax as recognized by curl/wget/etc.
You have to manually list all addresses, wildcard suffixes aren't supported.
Juju itself doesn't support wildcard or CIDR notation, as we inherit the default Go ProxyFromEnviro nment implementation. (We actually copy it to change behavior slightly, as the built-in one doesn't let you change proxy values during the lifetime of a process.)
*We* could support that syntax, but it wouldn't help with any tools/applications that get deployed on those machines that don't support that syntax.
Also note, the settings that should be used for the *juju client* are likely not the same as the settings that should be set for the *controller*. Very specifically, the client is running on your laptop, which is very likely not running in the same network as the machine you are bootstrapping. (consider juju bootstrap aws, my laptop running in my home network should not have *its* network settings propagated to the machine running in aws. I might be running a proxy at home, but it shouldn't try to use that proxy from AWS.)
So we *should* be using separate settings for proxy as a client, vs what is passed in bootstrap config. While it is a little annoying in the times where you really are behind the same firewall, the right fix would be:
export http_proxy=blah
export no_proxy=blah
juju bootstrap --model-default http_proxy=blah --model-default no_proxy=blah