Scribing Template --Tues., Nov 12, 2013 at 2pm -- Santa Barbara
TOPIC: Failsafe Grouper
CONVENER: Jim Fox
SCRIBE: Mike Grady
# of ATTENDEES: 13
MAIN ISSUES DISCUSSED: Failsafe Grouper
- Architecture of typical Grouper deployment
- API for Grouper, more use because of using richer info from Grouper (permissions), ease of access (REST), OAuth styles, etc.
- Should have an Infinite series of replicas of DB, rather than single instance
- What should these replicas look like?
- "mini" Groupers
- could be de-normalized, to optimize for "is a member of" query .(Query to Grouper database itself averages 300ms, to their current LDAP thru API front end is 40ms. Haven't measured the performance yet of this proposed approach.)
- need an API layer that has smarts as to which grouper instance to send query to, I.e. a "router" function
- a single de-normalized form that could well accommodate any typical query
- what technologies are being looked at for these horizontal replicas?
- Elastic Search, based on Lucene, team at U Washington looked at variety of options, like this best so far as far as meeting the needs they foresee for this
- code that generates elastic search query from REST Grouper query
- also looking at as cache for student data
...
- Give me all the groups that a user is a member of, do you get all the results, and then filter the results based on the permissions of the caller as to which groups they can see? Results are filtered as they are collected. Same access protection as Grouper, but does it slightly differently.
- Washington does not have "view" controls on the descriptions of the groups, don't worry about that, and no complaints so far
ACTIVITIES GOING FORWARD / NEXT STEPS:
If slides are used in the session, please ask presenters to convert their slides to PDF and email them to acamp-info@incommon.org
Documentation on Univ Washington use of replica (cache) DBs can be found on:
...