Open Stack

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.

jamie



----- Original Message -----
> From: "michael mccune" <msm at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Wednesday, August 5, 2015 11:37:10 PM
> Subject: Re: [openstack-dev] [keystone] policy issues when generating trusts with different clients
> 
> On 08/05/2015 02:34 AM, Steve Martinelli wrote:
> > I think this is happening because the last "session" created was based
> > off of trustee_auth. Try creating 2 sessions, one for each user (trustor
> > and trustee). Maybe Jamie will chime in.
> 
> just as a followup, i tried creating new Session objects for each client
> and i still get permission errors. i'm going to dig into the trust
> permission validation stuff a little.
> 
> mike
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>