Grouper Developers Forum

["Jessica Bibbee" <>]

Grouper Working Group Meeting
May 30, 2007

 

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

Dave Donnelly, Stanford U.

Gary Brown, U. Bristol

James Cramton, Brown U.
Joy Veronneau, Cornell U.
Bill Kasenchar, U. Pennsylvania
Ann West, EDUCAUSE/Internet2

Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

 

New *Action Items*
[AI] {Blair and Tom} will discuss where hooks or points of control ought to exist , for presentation back to the Group.

 

*Agenda*

1. v1.2.0 - release before v1.1 DB compatibility is ready?
  . outstanding issues
  . documentation
  . release and release candidate target dates
  . release logistics
2. grouper_memberships.membership_uuid index (c.f. James Cramton's email, 29-May-07)

3. Review of "hooks" conference call; likely Grouper hooks (cf. Lynn McRae's email to the signet-dev list on 25-May-07)
4. Integration with newly released Signet v1.2.0 

 

*Discussion*

 

-v1.2.0 - release before v1.1 DB compatibility is ready?-

{Tom} reiterated that the Grouper v1.2.0 release will not include support for the v1.0 schema. {Blair} said it might be offered as an extension to v1.2.0 once it is readied. The v1.2.0 schema is fixed, so those using it should experience no new change, in this regard, with the new release. {Joy and James} agreed that a later offering for v1.0 schema support would be acceptable. {James} said Brown is not close enough to running v1.2.0 in production, but neither do they need the v1.0 schema support. Requests or feedback should be made to the Grouper-user mailing list.

 

{Blair} said the API should be ready to tag by the end of the week; most of the changes at this point will be documentation related. He will coordinate with {Gary} for the packaging of Release Candidate 3 and {Tom} will announce the release soon after. Note, the API will skip the RC 2 stage and catch up to the QuickStart and UI for RC 3.

 

The official Grouper release of v1.2.0 should happen 2 weeks after the RC 3, aiming for June 15th or 18th. During those weeks, {Tom and Jessica} will work on finalizing documentation and {Blair and Gary} will address any performance issues, if any, raised with RC 3.

 

-index on grouper_memberships.membership_uuid (c.f. James Cramton's email, 29-May-07)-

{James} shared Brown's progress with the Group; they are focusing on provisioning groups into their database. They were getting a high I/O wait, and so eventually added an index on grouper_memberships.membership.uuid, with the result improving by more than 90% in most queries. In his email, he requested that this field be indexed in the default configuration. {Blair} said he would take a look at it, likely adding the index to HEAD.

 

{James} mentioned something called bookstore, whose only real association comes in description. This makes it difficult to search, and there is no way to delete a description in the API; the only option is to change it to an empty string.

 

When {James} tries to delete groups that are no longer in LDAP, an exception is reported. This issue just came up, and he will pass additional information to the Grouper-users mailing list as is available.

 

-Review of "hooks" conference call; likely Grouper hooks-
{Tom} asked the Group about which kind of support there ought to be to facilitate 3rd party extensions to what is currently private areas of the Signet/Grouper API. He pointed them to Lynn McRae's email to the signet-dev mailing list on 25-May-07. [0] {Tom} mentioned the discussion around synchronous/asynchronous capabilities and plugins that would act as listeners. They do not want to limit how many 3rd party plugins can hook in.

 

{Gary} expressed how he would like to batch changes when assembling custom groups with many different attributes and veto how a group is changed, before saving. Now, you must validate any changes in attributes one at a time. He also mentioned that now, you must create a group before adding attributes, and if the attributes were incorrect, that group would hang undefined. He said this would also be relevant for updates, meaning that there would be a site-specific object to check that if it is consistent with the update.

 

Precommit hooks would satisfy some of these concerns; {Tom} described a need at Chicago for a membership precommit hook. They will soon begin to discuss the design aspects of indirect commits of a direct membership change. They will develop a suite of use cases regarding general change notification requirements.

 

{Gary} restated his desire to have a way to easily bundle a number of hooks into one package, such that you could work with several packages more easily than a larger number of ungrouped plugins. It should also protect plugins, so that dropping in one plugin will not drop out another; i.e., it should maintain the independence of independent things.

 

[AI] {Blair and Tom} will discuss where hooks or points of control ought to exist, for presentation back to the Group. After their response, a follow-up hooks call will be scheduled and invitations sent to interested individuals.

 

-Integration with newly released Signet v1.2.0-

The latest release of Signet, v1.2.0, is now available. {Dave} reported that they have not done the aggression testing; it is compatible with the Subject API v0.2.2. {Tom} voiced an invitation for volunteers who were ready to mesh Signet with Grouper and provide feedback to the dev- or users- lists.

 

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

 

""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

[0] C.f. Lynn McRae's email to the signet-dev list on 25-May-07)

Signeteers,
Here are some talking points and proposals on the notion being explored for program hooks to simplify extending Signet and Grouper functionality at a site without customizing the underlying code base.
Lynn
======================================
*Signet program hooks, some high level assertions ...*

   * Defined at specific points of program control to address common site-specific needs
   * This could provide provisioning hooks among other points of control
   * An easy to configure plugin (or similar) approach that keeps site code distinct from Signet (or Grouper) code
   * Not meant to obviate any need to customize the core code itself, but should provide high value coverage and ease of product extension.
   * need synch and async capabilities (do sync first -- it meets functional needs of both cases)
   * Each point of control should not be limited to a single "listener" but be capable of engaging multiple callouts in a site-specified order
   * Might provide a simpler more consistent template for adapter class handling in general
   * Keep initial implementation simple!  it can grow.

*Proposed Signet hooks*

1. Assignment, pre-commit
- For regular assignments and proxy assignments?
     - Known need for former (regular assignments)
- Requirement is to be able to
     - examine the assignment and approve/disapprove
     - ability to cancel the commit, with a reason code/message
     - possibly augment the assignment information?
- A synchronous invocation of a site specific module
- Uncommitted assignment object is passed as a parm
     - plugin needs to know Assignment API
     - plugin needs to know Subject API for grantor/grantee information

2. Assignment, post-commit
- For regular assignments and proxy assignments?
- Can be asynchronous
- Use case is to take a provisioning action, e.g., invoke message or a write to the directory
- Pass the assignment on the call?
     - compare assignment vs privilege changes

3. Assignment activation
- For regular assignments and proxy assignments?
- Can be asynchronous
- Not quite the same as post-commit, e.g., for future effective date, future prereq activation.  Also a provisioning use case.  (Do we need both?)

4. Assignment deactivation
- For regular assignments and proxy assignments?
- Can be asynchronous

5. Assignment reconciliation
- This is when Signet re-evaluates an assignment to see if it has met prerequisites or no longer meets conditions.
- Rules handle most of the need here
     - a rules interpreter could be implemented as just a builtin hook plugin
- call out should basically implement the same interface as rules, returning
   a boolean true/false evaluation

-- 
Jessica Bibbee, Technical Analyst
Internet2

mobile: +1-734-255-6644

Internet2 Workshops:
More fun than summer school
http://www.internet2.edu/workshops