Grouper Developers Forum

[Chris Hyzer <>]

Here is a short writeup on a change to how exceptions to work in grouper:

 

https://wiki.internet2.edu/confluence/display/GrouperWG/Exception+handling+in+Grouper

 

I will work on this sometime soon.

 

Regards,

Chris

 

From: Emily Eisbruch [mailto:]
Sent: Thursday, February 19, 2009 3:04 PM
To: Grouper Dev
Subject: [grouper-dev] Draft Minutes: Grouper Call 18-Feb-09

 

Grouper Call 18-Feb-09**

 

 *Attending*

 

Tom Barton, U. Chicago (Chair)

Gary Brown, Bristol U.   

Shilen Patel, Duke

Chris Hyzer, U. Penn

Tom Zeller, U. Memphis

Ann West, EDUCAUSE/Internet2  

Steve Olshansky, Internet2    

Emily Eisbruch, Internet2 (scribe)

 

Action Items

 

[AI] (Shilen) will create a Jira item for the UUID and last membership update issue. 

https://bugs.internet2.edu/jira/browse/GRP-228

 

[AI]  (TomZ) will confirm that Ldappc uses query filters to determine when a group was last modified. 

 

[AI]  (TomZ) will summarize the Ldappc discussion on the wiki:

https://wiki.internet2.edu/confluence/display/GrouperWG/LDAPPC+Next+Steps

 

[AI]  (Shilen) will reframe the Namespace Transition issue with an email to the list.

 

*Discussion*

 

Gary will lead the next call on 4-Mar-09. TomB and Chris will be at the JA-SIG meeting in Dallas.

 

Last Membership Update Issue

 

Shilen:  Should we prevent updating the modifyUUID and modifyTime for a group or stem when a member or privilege is added or deleted and instead create last_membership_change attributes on groups and stems?

 

How would this affect Ldappc, which does membership updates based on the time the group was last updated?

 

TomZ will look into possible dependency with Ldappc: 

[AI]  (TomZ) will confirm that Ldappc uses query filters to determine when a group was last modified. 

 

Chris noted that, long-term, if Ldappc is moved to notifications, then we may not need the last_membership_change field at all. 

 

[AI] (Shilen) will create a Jira item for the UUID and last membership update issue. 

https://bugs.internet2.edu/jira/browse/GRP-228

 

U Memphis Provisioning Experience: lessons for Ldappc

https://wiki.internet2.edu/confluence/display/GrouperWG/LDAPPC+Next+Steps

 

Tom has experienced some frustration with Lddapc code. A goal woud be for Ldappc classes to represent information being handled.

 

Suggestion to merge some of what U. Memphis has developed with the current Lddappc. Or wipe slate clean and use Nexus instead of Ldappc.

 

TomZ: U Memphis wrote Nexus to be shared, but Nexus became more customized with local use. Also, there are issues with Nexus not working with SPML V2.

 

What about using SPML for last mile?  Not sure what products support SPML.

 

What will be required to change Ldappc to work with the notification service that will be developed?

Suggestion: Ldappc should eventually have two modes/versions --- one for notification and one to do what it does now. 

 

Using Nexus with Active Directory was discussed, including issues of speed, throttling, and change queue.

 

Sometimes for troubleshooting, people need to look at both Grouper logs and LDAP server logs.  There are advantages to having two steps in provisioning. Using SPML file that Ldappc produces and then something else to stuff that into the target. 

 

Packaging questions – use VM?  Save for future discussion.

 

Summary of what to do about Ldappc in near future.

 

- Testing and code structure improvements

- Notification integration, though notification doesn’t exist yet, so may be too soon to start design?

- Possible variations on what comes out of Ldappc. Is it inband LDAP or might it dump something else out for something else for diagnostic or operational purposes?

- Packaging questions

- Enhancements of Ldappc to work better with Active Directory groups (currently need to use custom fields).

- Ldappc handling of group renames. 

[AI]  (TomZ) will summarize the LDAPPC discussion on the wiki:

https://wiki.internet2.edu/confluence/display/GrouperWG/LDAPPC+Next+Steps

 

Unchecked Exceptions

 

Chris noted that Java seems to be moving towards unchecked exceptions. The group agreed it’s a good idea to have unchecked exceptions.  Chris will write up something on this.

 

Namespace Transition

 

[AI]  (Shilen) will reframe the Namespace Transition issue with an email to the list.

 

 

Next Call

 

Next Call:  Wed., 4-Mar-09 at noon ET 

 

 

 

 

Emily Eisbruch, Technology Transfer Analyst

Internet2

office: +1734-352-4996 | mobile +1-734-730-5749

 

Spring 2009 Internet2 Member Meeting

April 27-29, Arlington, Virginia

events.internet2.edu/2009/spring-mm/