Mistral

Mistralclient - TypeError: object.new(thread.lock) is not safe, use thread.lock.new()

Bug #1688518 reported by Harald Jensås on 2017-05-05

This bug affects 4 people

Affects		Status	Importance	Assigned to	Milestone
	Mistral	Fix Released	High	Juan Antonio Osorio Robles	Mistral rocky-1 "r1"
	tripleo	Fix Released	Medium	Juan Antonio Osorio Robles	tripleo queens-1

Bug Description

While testing a change in instack_undercloud (https://review.openstack.org/437544), I keep hitting this mistralclient error. I don't see it every time, but often.

The mistral client code in undercloud.py:
    user, password, project, auth_url = _get_auth_values()
    auth_kwargs = {
        'auth_url': auth_url,
        'username': user,
        'password': password,
        'project_name': project,
        'project_domain_name': 'Default',
        'user_domain_name': 'Default',
    }
    auth_plugin = ks_auth.Password(**auth_kwargs)
    sess = session.Session(auth=auth_plugin)

    mistral = mistralclient.client(
        mistral_url=mistral_url,
        session=sess)

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 1785, in install
    _post_config(instack_env)
  File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 1612, in _post_config
    session=sess)
  File "/usr/lib/python2.7/site-packages/mistralclient/api/client.py", line 19, in client
    return client_v2.Client(auth_type=auth_type, **kwargs)
  File "/usr/lib/python2.7/site-packages/mistralclient/api/v2/client.py", line 42, in __init__
    req = copy.deepcopy(kwargs)
  File "/usr/lib64/python2.7/copy.py", line 163, in deepcopy
    y = copier(x, memo)
  File "/usr/lib64/python2.7/copy.py", line 257, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/usr/lib64/python2.7/copy.py", line 190, in deepcopy
    y = _reconstruct(x, rv, 1, memo)
  File "/usr/lib64/python2.7/copy.py", line 334, in _reconstruct
    state = deepcopy(state, memo)
  File "/usr/lib64/python2.7/copy.py", line 163, in deepcopy
    y = copier(x, memo)
  File "/usr/lib64/python2.7/copy.py", line 257, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/usr/lib64/python2.7/copy.py", line 190, in deepcopy
    y = _reconstruct(x, rv, 1, memo)
  File "/usr/lib64/python2.7/copy.py", line 334, in _reconstruct
    state = deepcopy(state, memo)
  File "/usr/lib64/python2.7/copy.py", line 163, in deepcopy
    y = copier(x, memo)
  File "/usr/lib64/python2.7/copy.py", line 257, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/usr/lib64/python2.7/copy.py", line 190, in deepcopy
    y = _reconstruct(x, rv, 1, memo)
  File "/usr/lib64/python2.7/copy.py", line 329, in _reconstruct
    y = callable(*args)
  File "/usr/lib64/python2.7/copy_reg.py", line 93, in __newobj__
    return cls.__new__(cls, *args)
TypeError: object.__new__(thread.lock) is not safe, use thread.lock.__new__()

Revision history for this message

Bob Fournier (bfournie) wrote on 2017-05-05:

I'm also seeing this when I install the Undercloud. I'm basically following the undercloud install procedure here - http://tripleo.org/installation/installation.html using latest trunk repositories on a fresh install of CentOS. It happens every time.

I can get around it by using stable/ocata repos.

Revision history for this message

Harald Jensås (harald-jensas) wrote on 2017-05-05:

I think this bug is already fixed with this commit:

commit 83b3d0d39cb8072682fac74f6a40877030e91c18
Author: Juan Antonio Osorio Robles <email address hidden>
Date: Fri Mar 17 18:03:29 2017 +0200

Accept keystone session in client

    This already has auth configured, and allows us to re-use the session
    even with other clients. Currently this is not used by the CLI; however
    this is useful when instantiating the mistral client from a python
    script or from another service.

Change-Id: I4fccb4117db11c966ac3f17ec6d2a53c657378e8

diff --git a/mistralclient/api/v2/client.py b/mistralclient/api/v2/client.py
index 6758909..166cbf8 100644
--- a/mistralclient/api/v2/client.py
+++ b/mistralclient/api/v2/client.py
@@ -39,6 +39,9 @@ _DEFAULT_MISTRAL_URL = "http://localhost:8989/v2"

class Client(object):
def __init__(self, auth_type='keystone', **kwargs):
+ # We get the session at this point, as some instances of session
+ # objects might have mutexes that can't be deep-copied.
+ session = kwargs.pop('session', None)
req = copy.deepcopy(kwargs)

Emilien Macchi (emilienm) on 2017-05-05

Changed in tripleo:
milestone:	none → pike-2
importance:	Undecided → Medium
status:	New → Triaged

Emilien Macchi (emilienm) on 2017-06-08

Changed in tripleo:
milestone:	pike-2 → pike-3

Emilien Macchi (emilienm) on 2017-07-05

Changed in tripleo:
status:	Triaged → In Progress

Revision history for this message

Marios Andreou (marios-b) wrote on 2017-07-06:

not that this issue is also discussed at https://bugzilla.redhat.com/show_bug.cgi?id=1467645

Emilien Macchi (emilienm) on 2017-07-30

Changed in tripleo:
milestone:	pike-3 → pike-rc1

Emilien Macchi (emilienm) on 2017-07-31

Changed in tripleo:
milestone:	pike-rc1 → queens-1

Revision history for this message

Ben Nemec (bnemec) wrote on 2017-08-09:

Closing as fixed since it appears the Mistral patch has merged and nobody has chimed in to say it didn't fix the problem for them.

Changed in tripleo:
status:	In Progress → Fix Released

Dougal Matthews (d0ugal) on 2018-04-20

Changed in mistral:
status:	New → Confirmed
importance:	Undecided → High
milestone:	none → rocky-1
status:	Confirmed → Fix Released

Dougal Matthews (d0ugal) on 2018-05-18

Changed in mistral:
assignee:	nobody → Juan Antonio Osorio Robles (juan-osorio-robles)
Changed in tripleo:
assignee:	nobody → Juan Antonio Osorio Robles (juan-osorio-robles)