[Rdo-list] consoleauth package?

[Nikola Đipanov]

On 11/06/13 13:38, Dennis Jacobfeuerborn wrote:
> 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?
> 

As I suspected,

I think you've hit a known bug. See
https://bugs.launchpad.net/nova/+bug/1186123.

You can apply the linked patch - and it will be in the next grizzly
release we do by default.

Thanks,

N.

> Regards,
>   Dennis
>