On Oct 1, 2014 12:37 AM, "Adam Young" <ayo...@redhat.com> wrote:
> 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
>>>>> 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 -
>>         -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

Cinder backups. These do many swift operations over a long period, often
hours. They should probably be converted to trusts, but I'd need some
guidance do so.
OpenStack-dev mailing list

Reply via email to