Bug 853151

Summary:	"No object (name: translator) has been registered for this thread" due to private threading
Product:	Red Hat Enterprise Linux 6	Reporter:	Jan Pokorný [poki] <jpokorny>
Component:	luci	Assignee:	Jan Pokorný [poki] <jpokorny>
Status:	CLOSED ERRATA	QA Contact:	Cluster QE <mspqa-list>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.3	CC:	cluster-maint, fdinitto, jruemker, rsteiger
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	luci-0.26.0-15.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-21 08:22:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	826951

Description Jan Pokorný [poki] 2012-08-30 15:34:07 UTC

PWorker(threading.Thread) from luci/lib/ricci_helpers represents
a partly separated environment from its per-request thread.
One of the side-effects is that "translator" is not present
natively as in case of the framework-managed threads.

As a consequence, a request towards ricci handled by PWorker
can, if any error/exception occur, can be silently dropped.
The symptoms are:
- unexpected behavior: looks like the action has never been initiated
  by the user
- messages like these in /var/log/luci/luci.log:

16:15:45,344 ERROR [luci.lib.ricci_helpers]
  No object (name: translator) has been registered for this thread
16:15:45,350 ERROR [luci.lib.ricci_helpers]
  Error retrieving batch number from rhel63-64kvm-1:
  No object (name: translator) has been registered for this thread

This is due to such circumstances that fulfillment of request towards
ricci (done via PWorker/private threading) will fail and the message
to be presented to the user is arranged as lazily translated string.
Apparently, this works well outside private threading (so the user
is informed correctly about the problem), but fails in private
threading environment lacking the explicitly set translator.


Based on brief investigation, there are two options to solve this:
a/ make lazily translated strings as standard strings
   - easy, but non-systemic solution
b/ try to register translator object in the private threading
   environment
   - seems like a right way to solve it
   - see [1] for further hints


Tested reproducer:

1. cluster added into luci
2. within luci, select specific cluster, then fence devices tab
3. add any fence device, using non-ascii for, e.g., name

Expected behavior in this case is that the user is visually
informed in the spirit of "this went wrong".  Currently, nothing
happens from user's standpoint, previous page is just refreshed.


[1] http://comments.gmane.org/gmane.comp.web.turbogears/46896

Comment 2 Jan Pokorný [poki] 2012-08-31 09:53:55 UTC

Correcting myself, expected behavior is that something sensible is pushed
into luci.log instead of "No object (name: translator)...".

That is to say the latter is failure to inform about the failure and we
want to see just that original one.

Comment 5 Jan Pokorný [poki] 2012-08-31 13:46:45 UTC

Upstream change:
http://git.fedorahosted.org/cgit/luci.git/commit/?id=0363e2c

Comment 13 errata-xmlrpc 2013-02-21 08:22:29 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0309.html