<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick <span dir="ltr"><<a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I did suggest another solution to Adam whilst we were in Vancouver, and<br>
this mirrors what happens in the real world today when I order something<br>
from a supplier and a whole supply chain is involved in creating the end<br>
product that I ordered. This is not too dissimilar to a user requesting<br>
a new VM. Essentially each element in the supply chain trusts the two<br>
adjacent elements. It has contracts with both its customers and its<br>
suppliers to define the obligations of each party. When something is<br>
ordered from it, it trusts the purchaser, and on the strength of this,<br>
it will order from its suppliers. Each element may or may not know who<br>
the original customer is, but if it needs to know, it trusts the<br>
purchaser to tell it. Furthermore the customer does not need to delegate<br>
any of his/her permissions to his/her supplier. If we used such a system<br>
of trust between Openstack services, then we would not need delegation<br>
of authority and "trusts" as they are implemented today. It could<br>
significantly simplify the interactions between OpenStack services.<br></blockquote><div><br></div><div>+1! I feel like this is the model that we started with in OpenStack, and have grown additional complexity over time without much benefit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
regards<br>
<span class="HOEnZb"><font color="#888888">David<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 03/06/2015 21:03, Adam Young wrote:<br>
> On 06/02/2015 12:57 PM, Mikhail Fedosin wrote:<br>
>> Hello! I think it's a good time to discuss implementation of trusts in<br>
>> Glance v2 and v3 api.<br>
>><br>
>> Currently we have two different situations during image creation where<br>
>> our token may expire, which leads to unsuccessful operation.<br>
>><br>
>> First is connection between glance-api and glance-registry. In this<br>
>> case we have a solution (<a href="https://review.openstack.org/#/c/29967/" target="_blank">https://review.openstack.org/#/c/29967/</a>) -<br>
>> use_user_token parameter in glance-api.conf, but it is True by default<br>
>> . If it's changed to False then glance-api will use its own<br>
>> credentials to authorize in glance-registry and it prevents many<br>
>> possible issues with user token expiration. So, I'm interested if<br>
>> there are some performance degradations if we change use_user_token to<br>
>> False and what are the reasons against making it the default value.<br>
>><br>
>> Second one is linked with Swift. Current implementation uploads chunks<br>
>> one by one and requires authorization each time. It may lead to<br>
>> problems: for example we have to upload 100 chunks, after 99th one,<br>
>> token expired and glance can't upload the last one, catches an<br>
>> exception and tries to remove stale chunks from storage. Of course it<br>
>> will fail, because token is not valid anymore, and that's why there<br>
>> will be 99 garbage objects in the storage.<br>
>> With Single-tenant mode glance uses its own credentials to upload<br>
>> files, so it's possible to create new connection on each chunk upload<br>
>> or catch Unauthorized exception and recreate connections only in that<br>
>> cases. But with Multi-tenant mode there is no way to do it, because<br>
>> user credentials are required. So it seems that trusts is the only one<br>
>> solution here.<br>
> The problem with using trusts is that it would need to be created<br>
> per-user, and that is going to be expensive.  It would be possible, as<br>
> Heat does something of this nature:<br>
><br>
> 1. User calls glance,<br>
> 2. Glance creates a trust with some limitation, either time or number of<br>
> uses<br>
> 3.  Trusts are used for all operations with swift.<br>
> 4. Glance should clean up the trust when it is complete.<br>
><br>
> I don't love the solution, but I think it is the best we have.  Ideally<br>
> the user would opt in to the trust, but in this case, it is kindof<br>
> implicit by them calling the API.<br>
><br>
><br>
> We should limit the trust creation to only have those roles (or a<br>
> subset) on the token used to create the trust.<br>
><br>
><br>
><br>
><br>
>> I would be happy to hear your opinions on that matter. If you know<br>
>> other situations where trusts are useful or some other approaches<br>
>> please share.<br>
>><br>
>> Best regards,<br>
>> Mike Fedosin<br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>