Open Stack

On 11/28/2012 05:23 PM, heckj wrote:
> To be a little more specific, what I'm trying to understand is the workflow beyond the initial request to a service with the trust concept already set up -
>
> Say Joe requests a snapshot to be taken of a volume, and wants that dumped into object storage. The service doing the snapshot takes a while (sorry, it's just slow) - and 30 minutes later the service (cinder in my little example) wants to write data to object storage (swift) - what allows this to happen? What interactions and with what data stored where?
OK, let me get a better write up going.  I'll try to post something in 
the next couple of days as far as how I think this is supposed to work, 
but the short form:


user joe creates a trust.  trustor is joe, trustee is cinder, tenant is 
joes_restaurant (eat at Joes!) and the role is what ever is required to 
write to swift, so we will call it swift_write.

when cinder goes to perform the action for joe, it authenticates to 
keystone passing its service token and the trust id.  In return, it gets 
back a token that has joe as the user_id, as well as all the other 
information specified by the trust.  It uses that token to write to swift.

So swift would have to be modified to know about trusts.

so the APIs would be something like

POST v3/trusts  (create a new one)
DELETE v3/trusts/<id>  (create a new one)
POST v3/tokens (get a token for a trust)

But I'll write it up in more detail.


>
> -joe
>
> On Nov 28, 2012, at 2:14 PM, heckj <heckj at mac.com> wrote:
>> Hey Adam -
>>
>> so what I'm missing on all of this is
>>
>> 1) what's the API and how does a service and user interact with it?
>>
>> 2) what's the gist of the code - have it in a github repo or something to see your initial implementation?
>>
>> Trust, delegation, impersonation - whatever - the need that you laid out in your blog post is great. Glance and Nova have the exact same needs
>> (the blog post isn't a spec, by the way - you should update the BP to point to something other than your motivations for making it)
>>
>> In terms of the choices, I'd like to see the API and how you've taken a stab at implementing it to suggest some possible solutions. With no other knowledge, I'm tempted to assert it should be it's own backend, even knowing that's relatively heavy weight.
>>
>> -joe
>>
>> On Nov 28, 2012, at 7:45 AM, Adam Young <ayoung at redhat.com> wrote:
>>> I have a very rudimentary Trust  (what I used to call Preauth https://blueprints.launchpad.net/keystone/+spec/trusts) implementation working with the SQL backend for Identity.
>>>
>>> With LDAP, I am not sure where I would store the trust information. The data for the trust itself is simply the uuid user_ids for the trustor and  trustee and tenant Id.  There is also a table for the roles, and a second table for the endpoints associated with the trust.While we could shoehorn this into the user object, I am not sure that there is an intuitive way to implement it in LDAP.
>>>
>>> I see three choices.
>>>
>>> 1.  Leave the Trusts in the identity schema.  This has the nice effect of keeping the user-ids as foreign keys.  It has the drawback of forcing an LDAP backend solution.
>>> 2.  Move the Trusts into the Token backend.  This will get avoid the issue of LDAP support.  It does mean that tokens, which is a schema that is high volume, read intensive, and populated by short lifespan entities, gets mixed with trusts, which is low volume, and long lived.
>>> 3. Move it into its own backend.  This seems a little heavy weight.
>>>
>>>
>>> Thoughts?
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev