[Planetlab-devel] sfa database

Fri Dec 2 17:37:36 EST 2011

yes, we're on the same page wrt duplication; what I have on my list at this early stage is specifically
. add user x authority relations (I'm referring to what is now labeled as 'researcher' and 'PI' in the current code); so that at the very least sfa can compute rights reliably from its own stuff
. add maybe/probably an ssh key in the user record; not 100% positive about that one yet 

as to the ssh key in the plc db, we could indeed come up with some trick, like with the tags system, to let people select one 'primary' key; but I was wondering if that would indeed do the trick; I mean people who have uploaded several keys will likely have these scattered on their different computers, so having to select one might just not be right either.

in my perspective however this is second order at this point unfortunately :)

-- Thierry

On Dec 2, 2011, at 8:36 PM, Tony Mack wrote:

> Hi Thierry,
> 
> Sorry, didn't notice the thread until now...
> 
> We should be more specific about what we are talking about. When we say SFA we are really talking about 3 independent services, a Registry, Aggregate and SliceManager. 
> 
> The SliceManager is just a proxy and manages no state, so lets ignore it for now. 
> 
> The Registry is a certificate authority that issues issues credentials. It seems to me like you are suggesting storing duplicating state in Registry so that credentials can be issued without having look up the access control for a object in some other system. That sounds nice and I can see why you'd want that. Aside from making it easier to bring SFA up in generic environments, it also has an added benefit of providing generic access control for systems that don't already have something in place. This could work as long as we stick to our existing model for syncing. To be specific, we should still consider the state in the backend system to be authoritative and SFA just holds a copy of the stuff it needs. SFA should forwarded any state modifying requests to the backend system first, and if that succeeds then SFA can update its copy. Any changes on the back end are pushed to SFA without question.  
> 
> Now lets move onto the Aggregate, which is what manages the state of the backend resources. The aggregate should be self contained and provide an interface that SFA can use to query and manipulate state.  I don't think you are suggesting duplicating any of the Aggregate's data in SFA, but if you are then my response is that I do not think this is a good idea. Let me know if you want me to discuss this one further or if you agree with me here.
> 
> Tony
> 
> ----- Original Message -----
> From: "Thierry Parmentelat" <thierry.parmentelat at inria.fr>
> To: "PlanetLab Development" <devel at planet-lab.org>
> Sent: Friday, December 2, 2011 10:32:31 AM
> Subject: Re: [Planetlab-devel] sfa database
> 
> So nobody really has anything to say on this one ?
> meanwhile I think I've reached the conclusion, although this is still fuzzy, that keeping track of one ssh key could be needed as well..
> 
> On Nov 30, 2011, at 6:40 PM, Thierry Parmentelat wrote:
> 
>> Hi folks
>> 
>> As you might know I've spent some time recently, trying to refactor the registry manager in order to make it more generic 
>> 
>> In the process I came across a rather painful issue, that I thought could use a bit of brainstorming here
>> 
>> In essence, I guess I would argue that the SFA db should keep track of at least some of the inter-object relationships
>> In particular for the user x authority at the very least
>> 
>> Right now SFA deeply relies on myplc to retrieve this information; I am referring to 'fill_record_info'; which digs into the myplc database to retrieve the object, its relationships, messes with hrns in the process (in addition this is utterly unefficient); all this is essentially a back and forth between sfa data and plc data to reconstruct relationships.
>> 
>> In order to illustrate my point, imagine a testbed that's entirely dumb, in that it has a rustic account management system (you'd be surprised how common this is; localized testbeds commonly just have a LDAP server somewhere to manage accounts and that's about it)
>> In such a case fill_record_info really can't do much; at first I thought this would only have cosmetic impact, and would only affect sfi show <>
>> But when I got to trying it out, I realized that because the requestor/authority relationship could not be properly reconstructed, no right would be granted to the requestor and thus nobody could do anything on the testbed
>> 
>> So, because this particular relationship is so crucial to the internals of SFA, I would suggest that this info becomes duplicated in the SFA db as well
>> Just checking if that would go against any fundamental design decision that I would have missed, otherwise if that's fine with everyone I would add this to my list (not in the near future, but on a bit longer term)
>> 
>> [[I would in a first implementation just add a very generic obj1 x obj2 x relation_type table so that more relationships can be kept track of locally if need be]]
>> 
>> -- Thierry
>> 
>> 
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.planet-lab.org
>> https://lists.planet-lab.org/mailman/listinfo/devel
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel