Bug 853151 - "No object (name: translator) has been registered for this thread" due to private threading
"No object (name: translator) has been registered for this thread" due to pri...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: luci (Show other bugs)
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Jan Pokorný
Cluster QE
Depends On:
Blocks: 826951
  Show dependency treegraph
Reported: 2012-08-30 11:34 EDT by Jan Pokorný
Modified: 2013-07-09 15:54 EDT (History)
4 users (show)

See Also:
Fixed In Version: luci-0.26.0-15.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-02-21 03:22:29 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 420273 None None None Never

  None (edit)
Description Jan Pokorný 2012-08-30 11:34:07 EDT
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
   - 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ý 2012-08-31 05:53:55 EDT
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ý 2012-08-31 09:46:45 EDT
Upstream change:
Comment 13 errata-xmlrpc 2013-02-21 03:22:29 EST
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.


Note You need to log in before you can comment on or make changes to this bug.