Open Stack

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