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?
Regards,
Dennis