On 08/05/2015 10:27 PM, Jamie Lennox wrote:
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:
We're working on a keystoneclient 2.0 that will remove all that old code.
Let me know if that fixes it for you.
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,
OpenStack Development Mailing List (not for usage questions)