vnc_api: connection refused traceback when no auth_token supplied

Bug #1297579 reported by John Hazen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenContrail
Fix Committed
Undecided
Prakash Bailkeri

Bug Description

My python looks like:

import keystoneclient.v2_0.client
import novaclient.v1_1.client
import quantumclient.v2_0.client
from vnc_api import vnc_api

keystone = keystoneclient.v2_0.client.Client(
        username = 'admin',
        password = 'admin',
        tenant_name = 'tenant1',
        auth_url = 'http://10.164.96.4:5000/v2.0')

# Create nova client for computing management.
nova = novaclient.v1_1.client.Client(
        username = 'admin',
        api_key = 'admin',
        project_id = 'tenant1',
        auth_url = 'http://10.164.96.4:5000/v2.0')

# Create VNC client for networking management.
vnc = vnc_api.VncApi(
        username = 'admin',
        password = 'admin',
        tenant_name = 'tenant1',
        api_server_host = '10.164.96.5')

And I get the following traceback:

root@contrail:~# python -i contrail_test.py
Traceback (most recent call last):
  File "contrail_test.py", line 28, in <module>
    api_server_host = '10.164.96.5')
  File "/usr/lib/python2.6/site-packages/vnc_api/vnc_api.py", line 160, in __init__
    retry_on_error=False)
  File "/usr/lib/python2.6/site-packages/vnc_api/vnc_api.py", line 327, in _request_server
    self._headers = self._authenticate(content, self._headers)
  File "/usr/lib/python2.6/site-packages/vnc_api/vnc_api.py", line 194, in _authenticate
    headers=self._DEFAULT_AUTHN_HEADERS)
  File "/usr/lib/python2.6/site-packages/requests/api.py", line 87, in post
    return request('post', url, data=data, **kwargs)
  File "/usr/lib/python2.6/site-packages/requests/api.py", line 44, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python2.6/site-packages/requests/sessions.py", line 279, in request
    resp = self.send(prep, stream=stream, timeout=timeout, verify=verify, cert=cert, proxies=proxies)
  File "/usr/lib/python2.6/site-packages/requests/sessions.py", line 374, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python2.6/site-packages/requests/adapters.py", line 206, in send
    raise ConnectionError(sockerr)
requests.exceptions.ConnectionError: [Errno 111] Connection refused

Digging into the code a bit, it seems like it's trying to authenticate to 127.0.0.1 (maybe the api is meant to be running on the contrail controller only?), and since keystone is not running locally, the connection is being refused.

I got a hint from our Juniper guy that I need to pass on auth_token, and this did indeed solve the problem. However, getting a traceback for trying to auth based on strange default values, seems broken to me. There's got to be a better way to test auth, and give a more user-friendly error message like:

"No auth_token supplied"


The contrail-api I'm using is: contrail-api-lib-1.03-386.el6.noarch.rpm

Tags: config
Revision history for this message
Prakash Bailkeri (prakashmb) wrote :

My analysis:
VncApi can be invoked with a “conf_file” option(when not specified default
is /etc/contrail/vnc_api_lib.ini). Library expects the keystone server
information from this file.

When auth token is not specified in parameter or authentication can’t be
done with given auth-token, VncApi fetches the auth_token from keystone.

In your case, the conf_file is not specified And /etc/contrail/vnc_api_lib.ini also doesn’t exists(or doesn’t contain keystone details), hence the attempt is made to communicate with default keystone server(which is localhost).

Solution:
1. If the auth token is not specified, call to fetch auth token from keystone should be done in try catch. In case of exception, give an error message “unable to authenticate”
2. If auth token is specified, and authentication fails, not attempt should be made to fetch token again. Instead return error.

Changed in opencontrail:
assignee: nobody → Prakash Bailkeri (prakashmb)
Changed in opencontrail:
status: New → Fix Committed
tags: added: config
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.