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:jamielen...@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.co...@hp.com> > > To: "OpenStack Development Mailing List (not for usage questions)" > > <openstack-dev@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:jamielen...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev