| 2014-02-11 07:56:45 |
Lance Bragstad |
description |
When creating trusts in Keystone, if 'impersonation' is not provided Keystone fails out in the backend code. This should probably be handed at the controller level to be consistent across all backends.
lbragstad@precise64:~/curl-examples$ cat create_trust.json
{
"trust": {
"expires_at": "2014-02-27T18:30:59.999999Z",
"project_id": "c7e2b98178e64418bb884929d3611b89",
"impersonation": true,
"roles": [
{
"name": "admin"
}
],
"trustee_user_id": "bf3a4c9ef46d44fa9ce57349462b1998",
"trustor_user_id": "406e6d96a30449069bf4241a00308b23"
}
}
lbragstad@precise64:~/curl-examples$ cat create_trust_bad.json
{
"trust": {
"expires_at": "2014-02-27T18:30:59.999999Z",
"project_id": "c7e2b98178e64418bb884929d3611b89",
"roles": [
{
"name": "admin"
}
],
"trustee_user_id": "bf3a4c9ef46d44fa9ce57349462b1998",
"trustor_user_id": "406e6d96a30449069bf4241a00308b23"
}
}
Using impersonation in the create_trust.json file returns a trust successfully:
lbragstad@precise64:~/curl-examples$ curl -si -H "X-Auth-Token:$TOKEN" -H "Content-type:application/json" -d @create_trust.json http://localhost:5000/v3/OS-TRUST/trusts
HTTP/1.1 201 Created
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 675
Date: Sun, 09 Feb 2014 04:36:56 GMT
{"trust": {"impersonation": true, "roles_links": {"self": "http://10.0.2.15:5000/v3/OS-TRUST/trusts/12ce9f7214f04c018384f654f5ea9aa5/roles", "previous": null, "next": null}, "trustor_user_id": "406e6d96a30449069bf4241a00308b23", "links": {"self": "http://10.0.2.15:5000/v3/OS-TRUST/trusts/12ce9f7214f04c018384f654f5ea9aa5"}, "roles": [{"id": "937488fff5444edb9da1e93d20596d4b", "links": {"self": "http://10.0.2.15:5000/v3/roles/937488fff5444edb9da1e93d20596d4b"}, "name": "admin"}], "expires_at": "2014-02-27T18:30:59.999999Z", "trustee_user_id": "bf3a4c9ef46d44fa9ce57349462b1998", "project_id": "c7e2b98178e64418bb884929d3611b89", "id": "12ce9f7214f04c018384f654f5ea9aa5"}}
When using the request without impersonation defined I get:
lbragstad@precise64:~/curl-examples$ curl -si -H "X-Auth-Token:$TOKEN" -H "Content-type:application/json" -d @create_trust_bad.json http://localhos
t:5000/v3/OS-TRUST/trusts
HTTP/1.1 500 Internal Server Error
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 618
Date: Sun, 09 Feb 2014 04:33:08 GMT
{"error": {"message": "An unexpected error prevented the server from fulfilling your request. (OperationalError) (1048, \"Column 'impersonation
' cannot be null\") 'INSERT INTO trust (id, trustor_user_id, trustee_user_id, project_id, impersonation, deleted_at, expires_at, extra) VALUES
(%s, %s, %s, %s, %s, %s, %s, %s)' ('b49ac0c7558a4450949c22c840db9794', '406e6d96a30449069bf4241a00308b23', 'bf3a4c9ef46d44fa9ce57349462b1998',
'c7e2b98178e64418bb884929d3611b89', None, None, datetime.datetime(2014, 2, 27, 18, 30, 59, 999999), '{\"roles\": [{\"name\": \"admin\"}]}')", "
code": 500, "title": "Internal Server Error"}} |
When creating trusts in Keystone, if 'impersonation' is not provided Keystone fails out in the backend code. This should probably be handed at the controller level to be consistent across all backends.
lbragstad@precise64:~/curl-examples$ cat create_trust.json
{
"trust": {
"expires_at": "2014-02-27T18:30:59.999999Z",
"project_id": "c7e2b98178e64418bb884929d3611b89",
"impersonation": true,
"roles": [
{
"name": "admin"
}
],
"trustee_user_id": "bf3a4c9ef46d44fa9ce57349462b1998",
"trustor_user_id": "406e6d96a30449069bf4241a00308b23"
}
}
lbragstad@precise64:~/curl-examples$ cat create_trust_bad.json
{
"trust": {
"expires_at": "2014-02-27T18:30:59.999999Z",
"project_id": "c7e2b98178e64418bb884929d3611b89",
"roles": [
{
"name": "admin"
}
],
"trustee_user_id": "bf3a4c9ef46d44fa9ce57349462b1998",
"trustor_user_id": "406e6d96a30449069bf4241a00308b23"
}
}
Using impersonation in the create_trust.json file returns a trust successfully:
lbragstad@precise64:~/curl-examples$ curl -si -H "X-Auth-Token:$TOKEN" -H "Content-type:application/json" -d @create_trust.json http://localhost:5000/v3/OS-TRUST/trusts
HTTP/1.1 201 Created
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 675
Date: Sun, 09 Feb 2014 04:36:56 GMT
{"trust": {"impersonation": true, "roles_links": {"self": "http://10.0.2.15:5000/v3/OS-TRUST/trusts/12ce9f7214f04c018384f654f5ea9aa5/roles", "previous": null, "next": null}, "trustor_user_id": "406e6d96a30449069bf4241a00308b23", "links": {"self": "http://10.0.2.15:5000/v3/OS-TRUST/trusts/12ce9f7214f04c018384f654f5ea9aa5"}, "roles": [{"id": "937488fff5444edb9da1e93d20596d4b", "links": {"self": "http://10.0.2.15:5000/v3/roles/937488fff5444edb9da1e93d20596d4b"}, "name": "admin"}], "expires_at": "2014-02-27T18:30:59.999999Z", "trustee_user_id": "bf3a4c9ef46d44fa9ce57349462b1998", "project_id": "c7e2b98178e64418bb884929d3611b89", "id": "12ce9f7214f04c018384f654f5ea9aa5"}}
When using the request without impersonation defined I get:
lbragstad@precise64:~/curl-examples$ curl -si -H "X-Auth-Token:$TOKEN" -H "Content-type:application/json" -d @create_trust_bad.json http://localhos
t:5000/v3/OS-TRUST/trusts
HTTP/1.1 500 Internal Server Error
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 618
Date: Sun, 09 Feb 2014 04:33:08 GMT
{"error": {"message": "An unexpected error prevented the server from fulfilling your request. (OperationalError) (1048, \"Column 'impersonation
' cannot be null\") 'INSERT INTO trust (id, trustor_user_id, trustee_user_id, project_id, impersonation, deleted_at, expires_at, extra) VALUES
(%s, %s, %s, %s, %s, %s, %s, %s)' ('b49ac0c7558a4450949c22c840db9794', '406e6d96a30449069bf4241a00308b23', 'bf3a4c9ef46d44fa9ce57349462b1998',
'c7e2b98178e64418bb884929d3611b89', None, None, datetime.datetime(2014, 2, 27, 18, 30, 59, 999999), '{\"roles\": [{\"name\": \"admin\"}]}')", "
code": 500, "title": "Internal Server Error"}}
According to the Identity V3 API, 'impersonation' is a requirement when creating a trust. https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-trust-ext.md#trusts |
|
