Open Stack

On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick <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.


>
> 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://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
> >
>
> __________________________________________________________________________
> 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/4d35ac66/attachment.html>