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