[openstack-dev] 2 Minute tokens

Adam Young ayoung at redhat.com
Tue Sep 30 21:33:00 UTC 2014


On 09/30/2014 12:21 PM, Sean Dague wrote:
> On 09/30/2014 11:58 AM, Jay Pipes wrote:
>> On 09/30/2014 11:37 AM, Adam Young wrote:
>>> On 09/30/2014 11:06 AM, Louis Taylor wrote:
>>>> On Tue, Sep 30, 2014 at 10:44:51AM -0400, Adam Young wrote:
>>>>> What are the uses that require long lived tokens?
>>>> Glance has operations which can take a long time, such as uploading and
>>>> downloading large images.
>>> Yes, but the token is only authenticated at the start of the operation.
>>> Does anything need to happen afterwards?
>> Funny you mention it... :) We were just having this conversation on IRC
>> about Nikesh's issues with some Tempest volume tests and a token
>> expiration problem.
>>
>> So, yes, a Glance upload operation makes a series of HTTP calls in the
>> course of the upload:
>>
>>   POST $registry/images <-- Creates the queued image record
>>   ...  upload of chunked body of HTTP request to backend like Swift ..
>>   PUT $registry/images/<IMAGE_ID> <-- update image status and checksum
>>
>> So, what seems to be happening here is that the PUT call at the end of
>> uploading the snapshot is using the same token that was created in the
>> keystone client of the tempest test case during the test classes'
>> setUpClass() method, and the test class ends up running for >1 hour, and
>> by the time the PUT call is reached, the token has expired.
> Yes... and there is this whole unresolved dev thread on this -
> http://lists.openstack.org/pipermail/openstack-dev/2014-September/045567.html
>
> 	-Sean
>

This is comparable to the HEAT use case that Keystone Trusts were 
originally designed to solve.

If the glance client knows the roles required to perform those 
operations, it could create the trust up front, with the  Glance Service 
user as the trustee; the trustee execute the trust when it needs the token.

Are there other cases besides the glance one that require long lived tokens?



More information about the OpenStack-dev mailing list