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-conducto...
>>>
>>>
>>> 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?
As I suspected,
I think you've hit a known bug. See
.
You can apply the linked patch - and it will be in the next grizzly
release we do by default.
Thanks,
N.