[Openstack-operators] Horizon dashboard looking form quantum in compute-node

Juan José Pavlik Salles jjpavlik at gmail.com
Tue May 7 20:04:07 UTC 2013


Found the real solution, add this in the dashboard local_settings.py :
#QUANTUM_ENABLED: If a Network Connection (Quantum) service is available
and configured in the Identity service catalog, set QUANTUM_ENABLED = True.
The project is expected to become a core OpenStack project in the Folsom
release. You can set also QUANTUM_ENABLED = False.
QUANTUM_ENABLED = True


2013/5/7 Juan José Pavlik Salles <jjpavlik at gmail.com>

> Hi guys i found a workaround for this problem, it's not the best one
> though. I installed redir (a TCP redirector) listening on the dashboard
> host, this software takes the TCP connection from the dashboard to the
> quantum-api and redirect it to the real quantum-api server:
>
> redir --debug --laddr=172.19.136.11 --lport=9696 --caddr=172.19.136.2
> --cport=9696
>
> It works, but i don't want to do this on my production enviroment.
>
>
>
>
> 2013/5/7 Juan José Pavlik Salles <jjpavlik at gmail.com>
>
>> Sorry, i'm running Grizzly with Ubuntu 12.04 LTS. I think i could fix
>> this problem installing quantum-server on the same server running the
>> dashboard, but that'd break my deployment idea. What do you think?
>>
>>
>> 2013/5/6 Juan José Pavlik Salles <jjpavlik at gmail.com>
>>
>>> Hi guys now i'm dealing with a problem between horizon and my quantum
>>> api. When i click into de networks in horizon i get "*Error: *Network
>>> list can not be retrieved." so i checked the dashboard error.log file and
>>> this is what i've:
>>>
>>> [Mon May 06 19:51:17 2013] [error] \x1b[31;1mRecoverable error: [Errno
>>> 111] Connection refused\x1b[0m
>>> [Mon May 06 19:51:18 2013] [error] \x1b[31;1mRecoverable error: [Errno
>>> 111] Connection refused\x1b[0m
>>>
>>> I assumed this message means that it's not possible to reach
>>> quantum-server so i used the console client:
>>>
>>>  root at locro:~# quantum --os-username=admin --os-tenant-name=admin
>>> --os-password=XXX --os-auth-url=http://172.19.136.1:35357/v2.0 net-list
>>>
>>> +--------------------------------------+-------+-----------------------------------------------------+
>>> | id                                   | name  | subnets
>>>                             |
>>>
>>> +--------------------------------------+-------+-----------------------------------------------------+
>>> | 94fb127a-03e4-41a1-b397-8eefd2ede11b | vlan1 |
>>> cb5bbc6f-a380-4abd-8e85-b55e977adc0f 172.16.16.0/24 |
>>>
>>> +--------------------------------------+-------+-----------------------------------------------------+
>>> root at locro:~#
>>>
>>> It works just great, but what's the problem then? I checked my endpoints
>>> and services:
>>>
>>> root at locro:~# keystone --os-username=admin --os-tenant-name=admin
>>> --os-password=XXX --os-auth-url=http://172.19.136.1:35357/v2.0endpoint-list
>>>
>>> +----------------------------------+-----------+-------------------------------------------------+-------------------------------------------------+---------------------------------------------+----------------------------------+
>>> |                id                |   region  |
>>>  publicurl                    |                   internalurl
>>>     |                   adminurl                  |            service_id
>>>          |
>>>
>>> +----------------------------------+-----------+-------------------------------------------------+-------------------------------------------------+---------------------------------------------+----------------------------------+
>>> ...
>>> | 11c4108e48e34e0a9924f1266ab657ea | RegionOne |
>>> http://172.19.136.1:9696/            |
>>> http://172.19.136.1:9696/            |
>>> http://172.19.136.1:9696/          | 5899ffd62e994f929f0980d56391a84b |
>>> ...
>>>
>>> +----------------------------------+-----------+-------------------------------------------------+-------------------------------------------------+---------------------------------------------+----------------------------------+
>>> root at locro:~# keystone --os-username=admin --os-tenant-name=admin
>>> --os-password=XXX --os-auth-url=http://172.19.136.1:35357/v2.0service-list
>>>
>>> +----------------------------------+----------+--------------+------------------------------+
>>> |                id                |   name   |     type     |
>>> description          |
>>>
>>> +----------------------------------+----------+--------------+------------------------------+
>>> ...
>>> | 5899ffd62e994f929f0980d56391a84b | quantum  |   network    | OpenStack
>>> Networking service |
>>> ...
>>>
>>> +----------------------------------+----------+--------------+------------------------------+
>>>
>>> Everything looked ok. I thought that maybe... horinzon could be trying
>>> to reach quantum-server on the same host that it's running, so...:
>>>
>>> root at locro:~# nc -l 172.19.136.11 9696
>>> GET
>>> //v2.0/networks.json?shared=False&tenant_id=d1a1563eb7604307bc385817ab0adccf
>>> HTTP/1.1
>>> Host: 172.19.136.11:9696
>>> x-auth-token: 67a61c861b0542f1bd52021d0e39d5e1
>>> content-type: application/json
>>> accept-encoding: gzip, deflate
>>> accept: application/json
>>> user-agent: python-quantumclient
>>>
>>> Indeed it is. But... Why? It should take the quantum endpoint from
>>> keystone, shouldn't it? Somehow horizon is not using keystone endpoints to
>>> get the quantum server IP, is this correct? Is there a way i can tell
>>> horizon where my quantum-api is??? Thanks guys!!!
>>>  --
>>> Pavlik Juan José
>>>
>>
>>
>>
>> --
>> Pavlik Juan José
>>
>
>
>
> --
> Pavlik Juan José
>



-- 
Pavlik Juan José
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130507/3146aaa8/attachment.html>


More information about the OpenStack-operators mailing list