Open Stack

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?

-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