Open Stack

----- Original Message -----
> From: "michael mccune" <msm at redhat.com>
> To: openstack-dev at lists.openstack.org
> Sent: Friday, August 7, 2015 1:21:53 AM
> Subject: Re: [openstack-dev] [keystone] policy issues when generating trusts with different clients
> 
> 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.

Great

> 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)

It's safe in that if you force set it on the client then there isn't anything in the client that will override it, I don't know if i'd recommend it though.
 
> 2. are there plans for the new keystoneclient to automatically fill in
> user_id and project_id for Session/Auth based clients?

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

Absolutely.

So conceptually this is what we're trying to get to with keystoneclient. Keystone has 2 related but distinct jobs, one is to provide authentication for all the services and one is to manage it's own CRUD operations. Using sessions and auth plugins are authentication opreations and the existing keystoneclient should be used only for keystone's CRUD operations. This is the also the intent behind the upcoming keystoneauth/keystoneclient split where authentication options that are common to all clients are going to get moved to keystoneauth.

If you find yourself using a keystoneclient object for auth I would consider that a bug.

There is a larger question here about what sahara is doing with the user_id and project_id, typically this would be received from auth_token middleware or otherwise be implied by the token that is passed around. If you are passing these parameters to other clients we should fix those clients. For most projects this is handled by passing around the Context object which contains a session, a plugin and all the information from auth_token middleware.

> thanks again for the help,
> 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
>