| 2015-12-02 04:13:57 |
Steve Martinelli |
bug |
|
|
added bug |
| 2015-12-02 04:14:02 |
Steve Martinelli |
keystone: importance |
Undecided |
Critical |
|
| 2015-12-02 04:14:05 |
Steve Martinelli |
keystone: status |
New |
Triaged |
|
| 2015-12-02 04:14:17 |
Steve Martinelli |
bug task added |
|
pycadf |
|
| 2015-12-02 04:15:32 |
Steve Martinelli |
description |
With the latest pycadf release (2.0.0), there is a more strict validation on the ID fields of various CADF resources, in this case, the initiator is failing to validate some keystone user IDs.
This only happens when multi-domains are configured. An ID for a user in a multi-domain setup is in fact two IDs concatenated together.
The code to check for a valid ID / UUID is:
def is_valid(value):
"""Validation to ensure Identifier is correct.
"""
if value in ['target', 'initiator', 'observer']:
return True
try:
uuid.UUID(value)
except ValueError:
return False
else:
return True
A typical userID in a multi domain setup is: c79a927caef36ade4ed36679cd084fa45df4563f94af6a956fafa936889b4faf
When this is validated in pycadf, it fails:
>>> import uuid
>>> uuid.UUID("c79a927caef36ade4ed36679cd084fa45df4563f94af6a956fafa936889b4faf")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/uuid.py", line 134, in __init__
raise ValueError('badly formed hexadecimal UUID string')
ValueError: badly formed hexadecimal UUID string
Options: we can revert the change to pycadf and loosen the validation of IDs, or make keystone use a different value. |
With the latest pycadf release (2.0.0), there is a more strict validation on the ID fields of various CADF resources, in this case, the initiator is failing to validate some keystone user IDs.
This only happens when multi-domains are configured. An ID for a user in a multi-domain setup is in fact two IDs concatenated together.
The code to check for a valid ID / UUID is:
https://github.com/openstack/pycadf/blob/master/pycadf/identifier.py#L50-L60
def is_valid(value):
"""Validation to ensure Identifier is correct.
"""
if value in ['target', 'initiator', 'observer']:
return True
try:
uuid.UUID(value)
except ValueError:
return False
else:
return True
A typical userID in a multi domain setup is: c79a927caef36ade4ed36679cd084fa45df4563f94af6a956fafa936889b4faf
When this is validated in pycadf, it fails:
>>> import uuid
>>> uuid.UUID("c79a927caef36ade4ed36679cd084fa45df4563f94af6a956fafa936889b4faf")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/uuid.py", line 134, in __init__
raise ValueError('badly formed hexadecimal UUID string')
ValueError: badly formed hexadecimal UUID string
Options: we can revert the change to pycadf and loosen the validation of IDs, or make keystone use a different value. |
|
| 2015-12-02 04:16:36 |
Steve Martinelli |
description |
With the latest pycadf release (2.0.0), there is a more strict validation on the ID fields of various CADF resources, in this case, the initiator is failing to validate some keystone user IDs.
This only happens when multi-domains are configured. An ID for a user in a multi-domain setup is in fact two IDs concatenated together.
The code to check for a valid ID / UUID is:
https://github.com/openstack/pycadf/blob/master/pycadf/identifier.py#L50-L60
def is_valid(value):
"""Validation to ensure Identifier is correct.
"""
if value in ['target', 'initiator', 'observer']:
return True
try:
uuid.UUID(value)
except ValueError:
return False
else:
return True
A typical userID in a multi domain setup is: c79a927caef36ade4ed36679cd084fa45df4563f94af6a956fafa936889b4faf
When this is validated in pycadf, it fails:
>>> import uuid
>>> uuid.UUID("c79a927caef36ade4ed36679cd084fa45df4563f94af6a956fafa936889b4faf")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/uuid.py", line 134, in __init__
raise ValueError('badly formed hexadecimal UUID string')
ValueError: badly formed hexadecimal UUID string
Options: we can revert the change to pycadf and loosen the validation of IDs, or make keystone use a different value. |
With the latest pycadf release (2.0.0), there is a more strict validation on the ID fields of various CADF resources, in this case, the initiator is failing to validate some keystone user IDs.
This only happens when multi-domains are configured. An ID for a user in a multi-domain setup is in fact two IDs concatenated together.
The code to check for a valid ID / UUID is:
https://github.com/openstack/pycadf/blob/master/pycadf/identifier.py#L50-L60
def is_valid(value):
"""Validation to ensure Identifier is correct.
"""
if value in ['target', 'initiator', 'observer']:
return True
try:
uuid.UUID(value)
except ValueError:
return False
else:
return True
A typical userID in a multi domain setup is: c79a927caef36ade4ed36679cd084fa45df4563f94af6a956fafa936889b4faf
When this is validated in pycadf, it fails:
>>> import uuid
>>> uuid.UUID("c79a927caef36ade4ed36679cd084fa45df4563f94af6a956fafa936889b4faf")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/uuid.py", line 134, in __init__
raise ValueError('badly formed hexadecimal UUID string')
ValueError: badly formed hexadecimal UUID string
Options: we can revert the change to pycadf and loosen the validation of IDs, or make keystone use a different value.
This is the part of keystone that fails:
https://github.com/openstack/keystone/blob/master/keystone/notifications.py#L504-L505 |
|
| 2015-12-02 04:46:08 |
OpenStack Infra |
keystone: status |
Triaged |
In Progress |
|
| 2015-12-02 04:46:08 |
OpenStack Infra |
keystone: assignee |
|
Steve Martinelli (stevemar) |
|
| 2015-12-02 06:04:33 |
Steve Martinelli |
pycadf: status |
New |
In Progress |
|
| 2015-12-02 06:04:44 |
Steve Martinelli |
pycadf: assignee |
|
gordon chung (chungg) |
|
| 2015-12-02 06:04:49 |
Steve Martinelli |
pycadf: importance |
Undecided |
High |
|
| 2015-12-02 06:04:55 |
Steve Martinelli |
keystone: milestone |
|
mitaka-1 |
|
| 2015-12-02 16:36:44 |
Steve Martinelli |
keystone: milestone |
mitaka-1 |
mitaka-2 |
|
| 2015-12-02 16:36:48 |
Steve Martinelli |
keystone: importance |
Critical |
High |
|
| 2015-12-02 17:04:56 |
OpenStack Infra |
pycadf: status |
In Progress |
Fix Committed |
|
| 2015-12-04 15:00:40 |
Lance Bragstad |
keystone: status |
In Progress |
Invalid |
|
| 2015-12-04 15:01:15 |
Lance Bragstad |
keystone: status |
Invalid |
In Progress |
|
| 2015-12-22 08:22:14 |
Steve Martinelli |
pycadf: status |
Fix Committed |
Fix Released |
|
| 2016-01-19 03:09:28 |
Steve Martinelli |
keystone: milestone |
mitaka-2 |
mitaka-3 |
|
| 2016-01-19 03:09:34 |
Steve Martinelli |
keystone: assignee |
Steve Martinelli (stevemar) |
|
|
| 2016-01-19 03:10:18 |
Steve Martinelli |
keystone: status |
In Progress |
Confirmed |
|
| 2016-01-20 15:24:45 |
Ajaya Agrawal |
keystone: assignee |
|
Ajaya Agrawal (ajayaa) |
|
| 2016-01-20 17:09:36 |
OpenStack Infra |
keystone: status |
Confirmed |
In Progress |
|
| 2016-01-22 21:03:11 |
OpenStack Infra |
keystone: assignee |
Ajaya Agrawal (ajayaa) |
Lance Bragstad (lbragstad) |
|
| 2016-01-22 21:12:19 |
Steve Martinelli |
keystone: assignee |
Lance Bragstad (lbragstad) |
Ajaya Agrawal (ajayaa) |
|
| 2016-01-26 00:43:04 |
OpenStack Infra |
keystone: status |
In Progress |
Fix Released |
|
