Grouper Developers Forum

[Scott Koranda <>]

Michael, I also hear you (hard not to hear Michael, do we all agree?)

:-)

I don't have anything to add at this point. I think it will be up to
the Grouper team and Tom B. to balance user communities, use cases,
priorities, and then make the usual best guess based on 60% of the
needed information about how to proceed.

Either way I do expect Grouper will continue to evolve as it has been
to becoming as you wrote "a great tool which has no other equal and
until the marketplace picks up on it - if ever."

Cheers,

Scott

On Thu, Aug 14, 2014 at 3:22 PM, Michael R. Gettes 
<>
 wrote:
> 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
>