On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick <d.w.chadw...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev