devstack won't install with http_proxy set
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
devstack |
Fix Released
|
Low
|
Unassigned |
Bug Description
If you set http_proxy, then the keystone CLI appears to respect it. That means that connections intended for the local endpoint go to the proxy and then go wrong.
Further to this, the first failed connections are in keystone_data.sh - but since it doesn't picl up on any problem, the script continues and crashes much later than that with something that appears to be a glance error:
++ glance --os-auth-token --os-image-url http://
++ get_field 2
++ read data
usage: glance [--os-username OS_USERNAME] [--os-password OS_PASSWORD]
glance: error: argument --os-auth-token: expected one argument
+ KERNEL_ID=
+ '[' -n /home/localadmi
++ glance --os-auth-token --os-image-url http://
++ grep ' id '
++ get_field 2
++ read data
usage: glance [--os-username OS_USERNAME] [--os-password OS_PASSWORD]
glance: error: argument --os-auth-token: expected one argument
+ RAMDISK_ID=
+ glance --os-auth-token --os-image-url http://
usage: glance [--os-username OS_USERNAME] [--os-password OS_PASSWORD]
glance: error: argument --os-auth-token: expected one argument
++ failed
++ local r=2
++ set +o xtrace
The more useful keystone errors are:
No handlers could be found for logger "keystoneclient
Unable to communicate with identity service: (502, 'Cannot Connect'). (HTTP 400)
(repeated as it adds users, and tenants, then)
usage: keystone user-role-add --user_id <user-id> --role_id <role-id>
keystone user-role-add: error: argument --user_id: expected one argument
(repeated as it tries to set up things using '' for the ID, because the previous failures didn't kill the script)
The following patch makes it work for me:
diff --git a/stack.sh b/stack.sh
index a9cec3f..4d46b80 100755
@@ -1951,13 +1951,13 @@ if is_service_enabled key; then
fi
# keystone_data.sh creates services, admin and demo users, and roles.
- SERVICE_
+ http_proxy= https_proxy= SERVICE_
ADMIN_
bash $FILES/
# create an access key and secret key for nova ec2 register image
if is_service_enabled swift && is_service_enabled nova; then
- CREDS=$(keystone --os_auth_
+ CREDS=$(http_proxy= https_proxy= keystone --os_auth_
@@ -2033,7 +2033,7 @@ if is_service_enabled g-reg; then
ADMIN_
ADMIN_
- TOKEN=$(keystone --os_tenant_name $ADMIN_TENANT --os_username $ADMIN_USER --os_password $ADMIN_PASSWO
+ TOKEN=$(http_proxy= https_proxy= keystone --os_tenant_name $ADMIN_TENANT --os_username $ADMIN_USER --
# Option to upload legacy ami-tty, which works with xenserver
if [[ -n "$UPLOAD_
[ Additional notes: I've no idea how to make this work nicely if you truly do have a remote keystone server accessible via a proxy. And it appears that only the keystone client is actually affected by http_proxy, which is odd. ]
Changed in devstack: | |
importance: | Undecided → Low |
Changed in devstack: | |
status: | Invalid → Fix Released |
It's worse now - I think everything respects http_proxy rather than just keystone. I have a patch which I will put up when time allows.