Grouper Developers Forum

["Michael R. Gettes" <>]

Scott, I hear ya.

Yet, most of these orgs deploy Microsoft AD and all the stuff that comes 
along with that… 

i really don’t think the argument holds water.  So far, for us, there have 
been no lost messages.
The real issue is making sure the consumers and producers are solid.  It’s 
not AMQ itself, its 
the producers and consumers.  I really think we can make them reliable or 
easy to restart.

/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