Skip to Content.
Sympa Menu

grouper-dev - [grouper-dev] RE: HA grouper notes

Subject: Grouper Developers Forum

List archive

[grouper-dev] RE: HA grouper notes


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Jim Fox <>, "" <>
  • Subject: [grouper-dev] RE: HA grouper notes
  • Date: Wed, 8 Dec 2010 16:15:48 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

That is good information, thanks. Here is a wiki, anyone feel free to comment

https://spaces.internet2.edu/display/Grouper/Grouper+always+available+web+services

I agree about shib and think we should have a grouper attribute resolver that
uses the grouper client...

Thanks,
Chris

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


[mailto:]
On Behalf Of Jim Fox
Sent: Monday, December 06, 2010 10:45 PM
To:

Subject: [grouper-dev] HA grouper notes


re: Grouper dev action item regarding HA grouper

These are some questions that came up as we implemented an 'HA web
service', one that allows the service to respond quickly to the most
common requests and to continue service, for queries anyway, through
outages of the grouper registry. The design uses a clustered LDAP
service as a resource for selected requests.


1) Which queries will be HA?

About 90% of requests to our web service are two kinds of GETs:

. Is the user an effective member of a group?
. What groups is the user an effective member of?

The latter is the request our IdP makes.

2) Clients should be able to manually direct queries to the registry,
assuming that HA is the default.

3) The HA response must be complete and contain the same information
as a normal, registry response. A RESTful service normally includes
an ETag, or similar, with the response of any object that can also be
PUT, i.e. a membership. We do not make direct memberships HA for
this reason - our LDAP HA cannot generate the correct ETag.

4) The HA system must respond correctly to sequences such as this:

. One client PUTs a member to a group.
. Immediately, a different client GETs the member, using HA.

We allow PUTs to specify a 'synchronized' parameter which causes the
service to wait for LDAP update before returning a response.

5) The service must wait for all members of the LDAP cluster, not
just the master.

6) All appropriate ACls must be respected by the LDAP service.

7) If a Shibboleth IdP is using the Grouper attribute resolver it should
be HA as well.

Jim









Archive powered by MHonArc 2.6.16.

Top of Page