[juju-2.0-beta15] during the bootstrap stage the no-proxy config is ignored

Bug #1615719 reported by Felipe Reyes
8
This bug affects 1 person
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.openstack provider.go:1151 error listing servers: failed to get details for serverId: d5eb55ac-235f-4e83-be59-257f7622bdf8
caused by: authentication failed

The specific command line used is:

juju-2.0 bootstrap \
    --config image-stream=released \
    --config image-metadata-url=http://10.230.20.57/swift/v1/simplestreams/data/ \
    --config apt-http-proxy=http://10.230.64.2:3142/ \
    --config apt-https-proxy=http://10.230.64.2:3142/ \
    --config no-proxy="10.5.*,192.168.*,10.230.*" \
    --config use-default-secgroup=true \
    --config https-proxy=http://10.5.154.100:3128/ \
    --config http-proxy=http://10.5.154.100:3128/ \
    --config network=${OS_TENANT_NAME}_admin_net \
    --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.canonical.com:443 - ...
1471880799.535 12425 10.5.154.160 TCP_TUNNEL/200 6528372 CONNECT streams.canonical.com:443 - ...
1471880859.077 59369 10.5.154.160 TCP_MISS/504 3964 POST http://10.230.20.50:5000/v2.0/tokens - ...

The full log can found at: http://paste.ubuntu.com/23078665/

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
Curtis Hovey (sinzui)
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
Curtis Hovey (sinzui)
Changed in juju:
milestone: 2.0.1 → none
Revision history for this message
John A Meinel (jameinel) wrote :

--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 ProxyFromEnvironment 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

Revision history for this message
Heather Lanigan (hmlanigan) wrote :

Is this still a problem? Have the suggestions above helped?

Changed in juju:
status: Triaged → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for juju because there has been no activity for 60 days.]

Changed in juju:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.