Open Stack

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é
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130507/acab4b34/attachment.html>