Grouper Developers Forum

[Emily Eisbruch <>]

Grouper Call 9-Dec-09

 

 *Attending*

Tom Barton, U. Chicago  (Chair)

Gary Brown, Bristol   

Lynn Garrison, The Pennsylvania State University

Shilen Patel, Duke   

Chris Hyzer, U. Penn

Tom Zeller, U. Memphis

Steve Olshansky, Internet2

Emily Eisbruch, Internet2 (scribe)

 

*New Action Items*

[AI] (Gary) will add a link in the release process checklist for security issues and mention that U. Penn can do scanning for future releases.

[AI] (Chris) will start researching integration of Grouper with KIM workflows

[AI] (TomB) will talk with USC, UBC, UW and U. Arizona about testing Grouper KIM integration.

[AI] (Emily and SteveO) will confer on presenting the Grouper Q&A audio file on the Grouper website. 

 *Carry Over Action Items*

[AI ] (Everyone) update the upgrade change log wiki page as needed re jars and config files, and upgrade instructions.

https://spaces.internet2.edu/display/GrouperWG/Grouper+change+log+v1.5       

[AI] (Tom) will create Release Notes.  

 [AI] (SteveO) will update website and wiki as needed for the Grouper 1.5.0 release.  

*Grouper 1.5 Release Final Coordination*

The code has been frozen for the release of Grouper 1.5.0. TomB and SteveO will handle final steps, including creating release notes, archiving the Grouper 1.4.2 wiki pages, migrating the new Grouper 1.5.0 wiki pages into the regular/default pages, etc.

[AI] (Emily and SteveO) will confer on presenting the Grouper Q&A audio file on the Grouper website. 

Goal is to have the release ready on Friday, 11-Dec-09.

*Test and Release Process Review*

Are we doing enough during the release process to ensure that there are not vulnerabilities in the code? Do we have a deliberate enough process?

OOSP has a list of top 10 things to be concerned about.  Gary is certain we are fulfilling some of those items on the list, but a review would be worthwhile.

Chris said that U. Penn could do scanning to check for security issues as part of future releases.

 [AI] (Gary) will add a link in the release process checklist for security issues and mention that U. Penn can do scanning for future releases.

Testing different databases is useful. Is there a way to automate that testing? It could be helpful if Internet2 had a VM that could be used for testing Grouper with different databases at code freeze time, though there could be issues in keeping all the databases updated.  Is it practical to test all databases with all settings? While testing the Grouper 1.5.0 release, Chris got a new computer and reinstalled MySQL with different settings, causing some issues.

Oracle is available to be tested in-house by some of the developers. TomZ can test Postgress, which is used in production at U. Memphis.

Lynn noted that Penn. State University uses MySQL, but does not yet use Grouper in production.

It would be good to identify a Grouper campus that runs SQL Server and could help with testing. 

The conclusion for now is to become more deliberate about using the available campus resources.

*Build Number*

Chris suggests incorporating a build number into the version numbering scheme to eliminate the need to check the build date. One suggestion is using numbering such as:

1.5.0.23  where 23 is the build number.

Build number would increment as we test and revise. In Grouoper marketing, we could omit the last digits, an approach taken by Apache.   

Decision was to move in this direction for numbering Grouper and talk more about details as we get closer to the next release.

*Grouper KIM Development and Testing* 

Chris has been making small enhancements in Grouper due to the different ways of handling groups in Grouper versus in KIM. Chris has completed the coding and he needs to test and commit.

Chris plans to create a gap analysis document explaining differences in concepts (e.g. subjects and folders) between Grouper and KIM. 

There are still unsolved issues for campuses that already have a KIM deployment and want to move groups to Grouper.  

Q: Some organizations keep their system of record internal to KIM, not in LDAP or elsewhere. Can this cause issues?

A: Chris: If the system of record is KIM, there would be a need for a source adapter. This would be something to alert deployers to in the documentation. 

Lynn noted that the gap documentation Chris is going to create will be very helpful. Penn State is working to understand best practices. They are looking at using a central person repository. They would be interested in defining groups in Grouper and then pulling them to use for workflows in KIM.

Chris, noted that in light of the way KIM handles workflows with responsibilities, there is more integration work needed before Grouper can be used with KIM workflows. Chris will delve into this issue when the current group integration is complete.  A central question is whether it’s possible to add a group to a responsibility. Other institutions besides Penn State are also interested in this workflow question. 

[AI] (Chris) will start researching integration of Grouper with KIM workflows

Q: Where does the Grouper/KIM integration work go (proof of concept connector, & documentation)?

A: Chris: It will go in the Grouper CVS. Could go in the KIM subversion also.  Documentation will go on Grouper and KIM wikis, with pointers.

We will need campuses to test it and provide feedback.   Campuses already running Grouper in production would need to try the Grouper KIM integration in a proof-of-concept environment, until changes are committed in the head branch.

[AI] (TomB) will talk with USC, UBC, UW and U. Arizona about testing Grouper KIM integration.

*Branches*

Where should changes get committed?

https://mail.internet2.edu/wws/arc/grouper-dev/2009-12/msg00006.html

- GROUPER_1_5_BRANCH is for bug fixes.

- HEAD is for short-term functionality fixes, and where Chris is working on the Grouper and KIM integration. 

The 1.6 will be the next released version with enhancements, including Grouper KIM integration.

Then there will be a 2.0 version after 1.6.

Gary suggests waiting until we get Subversion before we start additional branching.

*Subject*

The fact Subject is handled as an external CVS project is no longer a problem, now that the version is tied to Grouper.

There were a few ideas about the status of Subject:

- Add paging and sorting of subjects, though this may not be possible across all implementations. This is easy to do w JDBC, not easy w LDAP. TomB remembered that JimF thought windowing may be possible with LDAP or JNDI.  

- Add subject implementation in the Grouper folders.  U Penn might contribute that.  

- Expanded Intersection capability, to handle certain rules.  This involves prerequisites and conditions, and is reminiscent of issues considered for the Signet project.

Next meeting will include a discussion of the Grouper roadmap.

Next Meeting: Wed., January 6, noon ET

Emily Eisbruch, Technology Transfer Analyst

Internet2

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

Winter 2010 ESCC/Internet2 Joint Techs

Hosted by the University of Utah - Salt Lake City, UT
January 31 - February 4, 2010

http://events.internet2.edu/2010/jt-slc/