<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/05/2015 10:39 AM, Dolph Mathews
wrote:<br>
</div>
<blockquote
cite="mid:CAC=h7gWhL8OD-ag5f50JQ3_dUsNOTZuoBQu3hHFTbj2=tuN68Q@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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>
</div>
</blockquote>
<br>
We could roll Glance into Nova, too, and get the same benefit.
There is a reason we have separate services. GLance shoud not Trust
Nova for all operations, just some.<br>
<br>
David's example elides the fact that there are checks built in to
the supply chain system to prevent cheating.<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAC=h7gWhL8OD-ag5f50JQ3_dUsNOTZuoBQu3hHFTbj2=tuN68Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>