On 08/05/2015 10:27 PM, Jamie Lennox wrote:
Hey Mike,

I think it could be one of the hacks that are in place to try and keep 
compatibility with the old and new way of using the client is returning the 
wrong thing. Compare the output of trustor.user_id and 
trustor_auth.get_user_id(sess). For me trustor.user_id is None which will make 
sense why you'd get permission errors.

Whether this is a bug in keystoneclient is debatable because we had to keep 
compatibility with the old options just not update them for the new paths, the 
ambiguity is certainly bad.

The command that works for me is:

trustor.trusts.create(
     trustor_user=trustor_auth.get_user_id(sess),
     trustee_user=trustee_auth.get_user_id(sess),
     project=trustor_auth.get_project_id(sess),
     role_names=['Member'],
     impersonation=True,
     expires_at=None)

We're working on a keystoneclient 2.0 that will remove all that old code.


Let me know if that fixes it for you.

hi Jamie,

this does work for me. but now i have a few questions as i start to refactor our code.

previously we have been handing around keystone Client objects to perform all of our operations. this leads to some trouble as we expected the user_id, and project_id, to be present in the client. so, 3 questions.

1. is it safe to set the user_id and project_id on a Client object?
(i notice that i am able to perform this operation and it would make things slightly easier to refactor)

2. are there plans for the new keystoneclient to automatically fill in user_id and project_id for Session/Auth based clients?

3. would it be better to transform our code to pass around Auth plugin objects instead of Client objects?

thanks again for the help,
mike


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to