[Rdo-list] consoleauth package?

Dennis Jacobfeuerborn dennisml at conversis.de
Tue Jun 11 11:38:06 UTC 2013


On 10.06.2013 18:15, Nikola Đipanov wrote:
> On 06/06/13 14:55, Pádraig Brady wrote:
>> On 06/06/2013 12:54 PM, Dennis Jacobfeuerborn wrote:
>>> On 06.06.2013 03:29, Pádraig Brady wrote:
>>>> On 06/06/2013 01:20 AM, Dennis Jacobfeuerborn wrote:
>>>>> Hi,
>>>>> I'm trying to get the console tab in horizon working but right now I only see "loading..." which times out after a while. According to the documentation novncproxy needs the consoleauth service and I found various pages on the web describing the installation of the openstack-nova-consoleauth rpm yet this doesn't seem to be available in the RDO repo.
>>>>> Is this no longer required or is it now part of another package?
>>>>
>>>> $ repoquery --file /usr/bin/nova-consoleauth
>>>> openstack-nova-console
>>>
>>> Ah, I wasn't paying attention to that package because the documentation describes nova-console as XenAPI specific and not to be confused with the separate nova-consoleauth. Thanks for the pointer.
>>>
>>> I now get the "shell" in the console tab but the vnc console itself doesn't work. What I found in the debug log is this:
>>>
>>> 2013-06-06 13:32:55.122 DEBUG nova.openstack.common.rpc.amqp [req-fba2d928-0c8b-4584-815a-17779cd96e2e None None] Making synchronous call on conductor ... multicall /usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py:583
>>>
>>> This call then times out after a while.
>>>
>>> The issue is that I disabled the conductor in nova.conf:
>>> ...
>>> [conductor]
>>> use_local=true
>>> ...
>>>
>>> I followed this page: http://cloudystuffhappens.blogspot.de/2013/04/understanding-nova-conductor-in.html
>>>
>>> So I'm not sure why vnc still tries to contact the conductor. Is the conductor service now a hard requirement for novncproxy?
>>
>> What might be happening here is that we're using novncproxy from
>> the "novnc" project rather than "nova", and things might have
>> gotten a little out of sync.
>>
>> Nikola do you know about this specific case,
>> or a way to quickly test the "nova" version of novncproxy?
>>
>
> Hey,
>
> I took a look at the code - and the situation is like this:
>
> * We do ship a slightly outdated nova-novncproxy service that what is
> currently in the stable grizzly branch but the changes are purely
> cosmetic (moving code around, no functional changes).
>
> * Both versions will try to use rpc only to talk to the consoleauth
> service and *never* try to talk to the conductor, so I am pretty sure
> that the multicall in the logs is not from the openstack-nova-novncproxy
> service (it should log to /var/log/nova/novncproxy.log - maybe try
> checking there if you haven't been already).
>
> I would guess that some answers could be found in the log file mentioned
> above. Alternatively make sure that the nova-consoleauth service is
> up-and-running as novncproxy will need to check creds with it.
>
> Let me know if any of this helped.

After bringing up nova-conductor (but keeping the "use_local=true" in 
place for the moment) the console started working (except that the 
keymap config doesn't seem to work and I get a "weird" key mapping).
So the conductor service does indeed seem to be necessary for the 
console work. Does the vnc code maybe rely on something else that pulls 
in this dependency?

Regards,
   Dennis




More information about the dev mailing list