Grouper Developers Forum

[Bryan Wooten <>]

Thanks all for the entertaining thread.

I have to agree with Scott on this one. Just think about the hassle of 
bringing up Grouper for a POC (ie quickstart).

Just my 2 cents.

-Bryan

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Michael R. Gettes
Sent: Thursday, August 14, 2014 2:23 PM
To: Scott Koranda
Cc: Chris Hyzer; Michael Hodges; 

Subject: Re: [grouper-dev] Draft Minutes: Grouper Call July 30, 2014

And if a small site can't run this, then maybe they should be hiring a firm 
to do it for them.

Can we think of any?  hmmm

/mrg

On Aug 14, 2014, at 4:06 PM, Scott Koranda 
<>
 wrote:

> 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