Open Stack

On 06/05/2015 10:39 AM, Dolph Mathews wrote:
>
> On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick 
> <d.w.chadwick at kent.ac.uk <mailto:d.w.chadwick at kent.ac.uk>> wrote:
>
>     I did suggest another solution to Adam whilst we were in
>     Vancouver, and
>     this mirrors what happens in the real world today when I order
>     something
>     from a supplier and a whole supply chain is involved in creating
>     the end
>     product that I ordered. This is not too dissimilar to a user
>     requesting
>     a new VM. Essentially each element in the supply chain trusts the two
>     adjacent elements. It has contracts with both its customers and its
>     suppliers to define the obligations of each party. When something is
>     ordered from it, it trusts the purchaser, and on the strength of this,
>     it will order from its suppliers. Each element may or may not know who
>     the original customer is, but if it needs to know, it trusts the
>     purchaser to tell it. Furthermore the customer does not need to
>     delegate
>     any of his/her permissions to his/her supplier. If we used such a
>     system
>     of trust between Openstack services, then we would not need delegation
>     of authority and "trusts" as they are implemented today. It could
>     significantly simplify the interactions between OpenStack services.
>
>
> +1! I feel like this is the model that we started with in OpenStack, 
> and have grown additional complexity over time without much benefit.

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.

David's example elides the fact that there  are checks built in to the 
supply chain system to prevent cheating.




>
>     regards
>     David
>
>     On 03/06/2015 21:03, Adam Young wrote:
>     > On 06/02/2015 12:57 PM, Mikhail Fedosin wrote:
>     >> 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.
>     > The problem with using trusts is that it would need to be created
>     > per-user, and that is going to be expensive.  It would be
>     possible, as
>     > Heat does something of this nature:
>     >
>     > 1. User calls glance,
>     > 2. Glance creates a trust with some limitation, either time or
>     number of
>     > uses
>     > 3.  Trusts are used for all operations with swift.
>     > 4. Glance should clean up the trust when it is complete.
>     >
>     > I don't love the solution, but I think it is the best we have. 
>     Ideally
>     > the user would opt in to the trust, but in this case, it is kindof
>     > implicit by them calling the API.
>     >
>     >
>     > We should limit the trust creation to only have those roles (or a
>     > subset) on the token used to create the trust.
>     >
>     >
>     >
>     >
>     >> 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
>     >>
>     >>
>     >>
>     >>
>     __________________________________________________________________________
>     >> OpenStack Development Mailing List (not for usage questions)
>     >> Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>     >
>     >
>     >
>     __________________________________________________________________________
>     > OpenStack Development Mailing List (not for usage questions)
>     > Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150605/de22010e/attachment.html>