Grouper Developers Forum

["Jessica Bibbee" <>]

Grouper Working Group Meeting
May 2, 2007

 

*Attendees*
Tom Barton, U. Chicago (chair)
Blair Christensen, U. Chicago

Dave Donnelly, Stanford U.
Gary Brown, U. Bristol

Kathryn Huxtable, U. Kansas

James Cramton, Brown U.
Joy Veronneau, Cornell U.
Bill Kasenchar, PSU
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

 

New *Action Items*
[AI] {Jessica} will send out an invitation to a side call focusing on hooks for the Grouper and Signet APIs.

Carry-Over *Action Items*
[AI] {James} will share performance numbers with the Grouper-users mailing list. (23-Apr-07)

*Agenda*

1. Brown University – Performance Testing Update

2. readying release v1.2.0
  . outstanding issues
  . release and release candidate target dates
  . release logistics
2. debrief sig-gro combined working group session at I2 Spring meeting
  . issues & follow-ups
3. "hooks" to enable 3rd party code to pre- or post-process key events internal to the API.

 

*Discussion*

 

- Brown University – Performance Testing Update-

{James} gave a brief update on the status of their performance testing. They ran the provisioning for v1.1 in 6 hours, though they are still compiling the results. In doing so, they discovered they have better visibility and subsequently that their superhero group was equivalent to the Grouper SuperUser; instead of a handful, there are 16K in this group. They will run v1.2 tonight, loading all of 11K groups. He intends to have aggregate numbers, as Cornell had to offer, and will share numbers as soon as they are available.

 

-Readying Grouper Release v1.2.0-

{Tom} walked through the latest updates leading up to the Grouper v1.2.0. He asked {Gary} about the custom UI capability to import/export files for memberships reporting, and whether that could be incorporated into the core, as opposed to the custom. {Gary's} reasoning for including it as standard is that there are too many assumptions to be made that ought to be at the site-level, not as a standard product decision. For example, it is impossible to know which attributes people will want to use in the export feature; he is cautious against imposing a particular structure across all sites. He encourages people to customize their own and share back with the community.

 

{Gary} reported that any remaining UI work should be independent of API changes, and the exact timing of {Blair's} work being completed should not impede any UI changes. Most of the remaining UI changes will be fall-out bugfixes of RC1 and RC2. {Tom} will work with [Jessica] to update documentation as is needed to move from Grouper v1.1 to v1.2.0.

 

{Blair} reported that he needs to review GrouperShell, though it works reliably on test systems; he hopes to have it ready for v1.2.

 

{Joy} asked if there is a utility to migrate from the old database to the new. {Tom} reported that there is not, and {Blair} said there is the  XML option and he hopes to have support ready for the v1.1 schema. {Joy} said the best choice is to create the new schema and reload all of their groups.

 

{Blair} estimated there is another 2 weeks of work to be done on the API, and given other tasks, 25-May is a likely target. Whether it is an official release or a release candidate (3) depends on how much user participation there is for performance testing before that date. It is unclear as to how many users are actually performing any testing on the current release candidates.

 

-Debrief sig-gro combined working group session at I2 Spring meeting - Issues & Follow-ups-

{Tom} focused the discussion the feedback from the field, namely from {Joy, Kathryn, James, and Anne Marie Alexander (Duke U.)}. {Tom} heard that there is a strong interest in having read and view being capable of being mapped into the LDAP group structure. {Kathryn} will be submitting this as a feature request for LDAPPC vNext.

 

Another item noted by {Kathryn} is that LDAPPC works for group information, but not for forward reference or isMemberOf style of information. LDAP is not well suited for certain kinds of provisioning, as it may be using an in-memory database that can introduce constraints.

 

{Tom] reported that he followed up with {Klara Jelinkova and Anne Marie} of Duke, and said they will be sharing some of their data. He mentioned a possible conference call with them, saying they may be in need of a workaround and that may feed back into the Grouper design.

 

- "Hooks" to enable 3rd party code to pre- or post-process key events internal to the API-

{Tom} briefly mentioned a future and separate conference call with discussion focused on hooks, which would allow for extending requirements towards both the Grouper and Signet APIs. {Tom} invited anyone to join that might be interested in having a clear means for 3rd party enhancements for processing key internal events. [AI] {Jessica} will send out an invitation to a side call focusing on hooks for the Grouper and Signet APIs.

 

The next Grouper Working Group call will be on Wednesday, May 16, 2007 at 12pm EDT.

-- 
Jessica Bibbee, Technical Analyst
Internet2

mobile: +1-734-255-6644

Internet2 R&E Network Members
Community, connected.
http://www.internet2.edu/renm/