[GAP] Update

[Rahul Doshi]

Hi Carl,

I haven¹t had chance to come up with architecture diagram yet but will
soon draw one and post it to the list.  To answer your question GAP in
itself is not multithreaded but we do achieve similar behavior by running
three separate instances of same GAP code base to provision groups in 389,
AD and isMemberOf attribute of 389 user objects.  What GAP is going to
update is completely driven by configuration file.  We do not maintain
separate codebase for each functionality.

Thanks,
Rahul

On 11/13/14, 11:03 AM, "Waldbieser, Carl" <waldbiec at lafayette.edu> wrote:

>Michael,
>
>Is there an architectural diagram of GAP somewhere?
>I was wondering if GAP is farming out group updates to multiple
>LDAP-updaters.
>At Lafayette, account memberships and group members must be kept in sync
>in application logic (our OpenLDAP directory service does not synchronize
>these values).  So I was also wondering if the components of GAP that
>update LDAP can distribute the tasks for updating group members and
>updating account memberships to separate workers?
>
>Thanks,
>Carl Waldbieser
>ITS System Programmer
>Lafayette College
>
>----- Original Message -----
>From: "Michael R. Gettes" <gettes at cmu.edu>
>To: identity-services-gap at lists.andrew.cmu.edu
>Sent: Thursday, November 13, 2014 10:31:34 AM
>Subject: [GAP] Update
>
>Hi All,
>
>I am hoping Rahul will be providing updates from this point forward.
>
>Based on discussions at TechX, CMU will continue to develop GAP as the
>grouper devs will be providing a basic capability within grouper so there
>will still be a need for something to provide efficient and fast LDAP
>provisioning (and possibly other provisioning capabilities).  Keep in
>mind while we have been concentrating on LDAP and AD, GAP could be
>extended to other capabilities if it is an appropriate mechanism to do
>so.  We already have about 10 institutions on this mailing list.  We do
>hope GAP is useful to others as we don¹t want this to be a CMU only piece
>of software.
>
>Rahul is concentrating on getting grouper 2.2.1 out the door but has a
>working prototype for batching of large changes to static group objects.
>Essentially, we are doing a read-ahead into the AMQ queue and applying up
>to 1000 adds or deletes in a single LDAP modify.  Initial testing gets
>group creation or deletion down to around 3-4 min for a group of 25,000.
>Keep in mind GAP already does periodic bulk updates and this change is to
>make normal incremental operations to static group objects even faster.
>At this time, we don¹t think there is much we can do to speed up
>isMemberOf operations.  We are getting more comfortable with the idea of
>sites like PSU and Indiana being able to use this successfully.  Our
>concern is we have made this work for CMU and code changes may be needed
>to be more flexible for different types of operating scenarios and DITs
>and so on.  So, the more who work on it, the better it will be for all.
>
>It was great seeing folks at TechX.
>
>/mrg
>
>_______________________________________________
>Identity-services-gap mailing list
>Identity-services-gap at lists.andrew.cmu.edu
>https://lists.andrew.cmu.edu/mailman/listinfo/identity-services-gap
>_______________________________________________
>Identity-services-gap mailing list
>Identity-services-gap at lists.andrew.cmu.edu
>https://lists.andrew.cmu.edu/mailman/listinfo/identity-services-gap