Skip to Content.
Sympa Menu

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

Subject: Grouper Developers Forum

List archive

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

Chronological Thread 
  • From: "Michael R. Gettes" <>
  • To: Scott Koranda <>
  • Cc: Chris Hyzer <>, Michael Hodges <>, "" <>
  • Subject: Re: [grouper-dev] Draft Minutes: Grouper Call July 30, 2014
  • Date: Thu, 14 Aug 2014 20:22:54 +0000
  • Accept-language: en-US

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


On Aug 14, 2014, at 4:06 PM, 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

Archive powered by MHonArc 2.6.16.

Top of Page