Open Stack

Jamie - thanks for the link to your blog.

I remember the Paris discussion :) And also noted the Vancouver discussion re. SDK not necessarily being targeted at service-service interactions. I sense there is renewed desire to maintain & improve swiftclient, and a few of us are interested in looking into the session support (but lacking free cycles right now :/). We need to figure out a nice way to maintain the v1 auth mode as and when sessions comes into the Connection - there was a very brief conversation in Vancouver around maybe encapsulating the v1 auth in a keystone-session-like object.

Alistair

> -----Original Message-----
> From: Jamie Lennox [mailto:jamielennox at redhat.com]
> Sent: 19 June 2015 02:27
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] V3 Authentication for swift store
> 
> 
> 
> ----- Original Message -----
> > From: "Alistair Coles" <alistair.coles at hp.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > Sent: Thursday, 18 June, 2015 4:39:52 PM
> > Subject: Re: [openstack-dev] V3 Authentication for swift store
> >
> >
> >
> > > -----Original Message-----
> > > From: Jamie Lennox [mailto:jamielennox at redhat.com]
> > > Sent: 18 June 2015 07:02
> > > To: OpenStack Development Mailing List (not for usage questions)
> > > Subject: [openstack-dev] [glance] V3 Authentication for swift store
> > >
> > > Hey everyone,
> > >
> > > TL;DR: glance_store requires a way to do v3 authentication to the
> > > swift backend.
> > >
> > > <snip>
> > >
> > > However in future we are trying to open up authentication so it's
> > > not limited to only user/password authentication. Immediate goals
> > > for service to service communications are to enable SSL client
> > > certificates and kerberos authentication. This would be handled by
> > > keystoneclient sessions but they are not supported by swift and it
> > > would require a significant rewrite of swiftclient to do, and the
> > > swift team has indicated they do not which to invest more time into
> > > their client.
> >
> > If we consider specifically the swiftclient Connection class, I wonder
> > how significant a rewrite would be to support session objects? I'm not
> > too familiar with sessions - is a session an object with an interface
> > to fetch a token and service endpoint url? If so maybe Connection
> > could accept a session in lieu of auth options and call the session
> > rather than its get_auth methods.
> >
> > If we can move towards sessions in swiftclient then that would be good
> > IMHO, since we have also have requirement to support fetching a
> > service token [1], which I guess would (now or in future) also be handled by
> the session?
> >
> > [1] https://review.openstack.org/182640
> >
> > Alistair
> >
> 
> So the sessions work is built on, and is modelled after requests.Session. It
> consists of two parts, the session which is your transport object involving things
> like CA certs, verify flags etc and an auth plugin which is how we can handle new
> auth mechanisms. Once coupled the interface looks very similar to a
> requests.Session with get(), post(), request() etc methods, with the addition that
> requests are automatically authenticated and things like the service catalog are
> handled for you. I wrote a blog post a while back which explains many of the
> concepts[2].
> 
> The fastest way I could see including Sessions into swiftclient would be to create
> new Connection and HttpConnection objects. Would this be something swift is
> interested in? I didn't mean to offend when saying that you didn't want to put
> any more time into the client, there was a whole session in Paris about how the
> client had problems but it was just going to limp along until SDK was ready. Side
> note, i don't know how this decision will be affected based on Vancouver
> conversations about how SDK may not be suitable for service->service
> communications.
> 
> Regarding service tokens, we have an auth plugin that is passed down from
> auth_token middleware that will include X-Service-Token in requests which I
> think swiftclient would benefit from.
> 
> 
> Jamie
> 
> [2] http://www.jamielennox.net/blog/2014/09/15/how-to-use-keystoneclient-
> sessions/
> 
> _________________________________________________________________
> _________
> 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