Grouper Users - Open Discussion List

[Tom Zeller <>]

From my point of view, for ldappcng :

Ease of deployability is inversely proportional to the number of
assumptions made about the provisioning environment. For example, if I
assume that all provisioning targets are ldap, then it is more
difficult to use ldappcng to provision an rdbms. So, deployability
increases with genericity.

Opposite to deployability, performance seems proportional to the
number of assumptions made about the provisioning environment. For
example, if I assume that all identifiers of group members can be
calculated using string concatenation instead of via ldap searches,
then I can avoid those ldap searches. So, performance decreases with
genericity.

I think we will want to reach a middle ground, with reasonable
assumptions so that provisioning is both deployable and performant.
"Fox Mode", fast and configurable.

The conversation I had with the fellow from Microsoft was that
state-based (diff then sync an entire object or all of an attribute's
values) systems for provisioning groups in real-time can be slow
because of the complexity of identifier resolution, where "slow" is a
minute, and where slowness increases with the number of resolutions
(members).

Incremental provisioning ("add member M to group G") is likely faster
than state-based since there are fewer bits to provision. But this is
where I am stuck. I do not think I can always assume that "add member
M to group G" results in adding "cn=M,dc=edu" as a value to the member
attribute of "cn=G,dc=edu". Instead, I think ldappcng would need to
resolve (via the Shib AttributeResolver) all attributes of all objects
changed, both before and after the change is made, compute the
difference in the resulting calculated provisioning, and then
provision that difference. This may not be faster than state-based
provisioning.

On Thu, Mar 17, 2011 at 9:56 AM, Michael R. Gettes 
<>
 wrote:
> Um, forgive me, but i keep hearing how difficult it is to do this... and I 
> am not appreciating why it is so difficult.  Should you, or anyone else, be 
> interested in educating me, i'd be interested in learning.
>
> /mrg
>
> On Mar 17, 2011, at 10:28, Tom Zeller wrote:
>
>> I was feeling a little depressed that ldappcng does not provision
>> groups or memberships in real-time. It should.
>>
>> We (Memphis) had Microsoft on campus the last two days to talk about
>> provisioning 
>> Live@edu,
>>  and it turns out they have a "new" plug-in to
>> ILM/FIM for 
>> Live@edu
>>  to provision groups - and it faces similar
>> issues. For example, "large" groups (where "large" = 30k members) are
>> recommended to be broken into smaller chunks, and the hardware
>> requirements (CPU, RAM) are different if groups are provisioned.
>>
>> The more assumptions one makes about how groups are provisioned, the
>> easier it is to do so performantly. A generic real-time group
>> provisioner seems difficult, but I think we can do it.
>>
>> TomZ
>>
>
>