Grouper Developers Forum

[Scott Koranda <>]

On Thu, Aug 14, 2014 at 2:22 PM, Chris Hyzer 
<>
 wrote:
> Scott, what if the messaging system were an easy to setup and very 
> inexpensive SaaS product?  (e.g. AWS).  Would that be acceptable for 
> smaller institutions who don’t want to run another component?

In my opinion, no. You are asking the organization to set up and pay
for a SaaS product when they might not have any such existing service
contracts and no easy way to procure one (I put LIGO in this
category--we have to approach funding agencies to ask for permission
to spend grant money on such things).

The thinking will go something like "I have my groups in Grouper and I
just need them put into LDAP. I did that before with ldappc, then
ldappc-ng, and then (with a bit more pain) the PSP. Now you tell me
there is this embedded messaging service, that I will not have to
bother with, until something doesn't work and a message is lost and I
have to track it down at which point I need to learn a bunch of stuff
about AMQ that I have no other use for".

I *do* get the (architectural) attraction of using a messaging service
with a bunch of consumers/provisioners and fully support the idea.
Most campuses I believe should be taking just such an approach. I just
think it should not be necessary for smaller organizations that want
to deploy Grouper, LDAP, and not much else.

Thanks,

Scott

>
> Thanks,
> Chris
>
> Ps. granted we need to address the ordering of messages in SQS which I 
> think we can do
>
> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Scott Koranda
> Sent: Thursday, August 14, 2014 2:54 PM
> To: Michael R. Gettes
> Cc: Michael Hodges; 
> 
> Subject: Re: [grouper-dev] Draft Minutes: Grouper Call July 30, 2014
>
> On Thu, Aug 14, 2014 at 1:35 PM, Michael R. Gettes 
> <>
>  wrote:
>> We share the same vision Michael.  Our changelog consumer makes use of the
>> AMQ library calls.  It shouldn’t be hard to substitute XYZ broker API to
>> make it compatible with Rabbit and so on.
>
> +1
>
> I understand the value proposition for making AMQ the preferred
> message broker, and a tight
> integration with Grouper makes sense to me, but I would like to see
> the changelog consumer
> flexible enough so that one could "easily" use a different message system.
>
> I would also appreciate an effort to standardize on the message format(s).
>
> I disagree with Michael about a change log consumer that provisions
> directly to LDAP. For smaller
> campuses and virtual organizations a change log consumer that directly
> provisions to LDAP (including
> a bulk synchronization mode or cycle) is preferred even if a messaging
> system like AMQ ends up being
> well integrated with Grouper. Having the additional message broker
> piece adds extra complexity
> that smaller organizations simply do not want to deal with. The
> Grouper team always has to make
> tradeoffs and decisions about where to invest limited effort and IMHO
> it is worth the effort to have
> a simple LDAP provisioner not bound to a messaging system that is
> known to support the major
> LDAP implementations (OpenLDAP, 389, Sun/Oracle, MS AD).
>
> Thanks,
>
> Scott K