[openstack-dev] [Glance][Keystone] Glance and trusts

Mikhail Fedosin mfedosin at mirantis.com
Tue Jun 2 16:57:03 UTC 2015


Hello! I think it's a good time to discuss implementation of trusts in
Glance v2 and v3 api.

Currently we have two different situations during image creation where our
token may expire, which leads to unsuccessful operation.

First is connection between glance-api and glance-registry. In this case we
have a solution (https://review.openstack.org/#/c/29967/) - use_user_token
parameter in glance-api.conf, but it is True by default . If it's changed
to False then glance-api will use its own credentials to authorize in
glance-registry and it prevents many possible issues with user token
expiration. So, I'm interested if there are some performance degradations
if we change use_user_token to False and what are the reasons against
making it the default value.

Second one is linked with Swift. Current implementation uploads chunks one
by one and requires authorization each time. It may lead to problems: for
example we have to upload 100 chunks, after 99th one, token expired and
glance can't upload the last one, catches an exception and tries to remove
stale chunks from storage. Of course it will fail, because token is not
valid anymore, and that's why there will be 99 garbage objects in the
storage.
With Single-tenant mode glance uses its own credentials to upload files, so
it's possible to create new connection on each chunk upload or catch
Unauthorized exception and recreate connections only in that cases. But
with Multi-tenant mode there is no way to do it, because user credentials
are required. So it seems that trusts is the only one solution here.

I would be happy to hear your opinions on that matter. If you know other
situations where trusts are useful or some other approaches please share.

Best regards,
Mike Fedosin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150602/b3fdfaeb/attachment.html>


More information about the OpenStack-dev mailing list