COmanage-Dev Call 29-May-09
*Attending*
Heather Flanagan, Stanford (Chair)
Digant Kasundra, Stanford
Ken Klingenstein, Internet2
Tom Barton, U. Chicago
Steven Carmody, Brown
RL "Bob" Morgan, U. Washington
Mike LaHaye, Internet2
Dan Pritts, Internet2
IJ Kim, Internet2
Renee Frost, Internet2
George Brett, Internet2
Ann West, EDUCAUSE, Internet2
Steve Olshansky, Internet2
Emily Eisbruch, Internet2 (scribe)
*New Action Items*
[AI] (Ken) will investigate setting up a video conference meeting with the SURFnet group during CAMP or Advanced CAMP in Philadelphia, June 15-19, 2009.
[AI] (Ken) will respond to the May 20 email from SURFnet, providing a summary of the discussion about collaborating on various aspects of COmanage.
*Carry Over Action Items*
[AI] (Ken) will work on COmanage scripting.
[AI] (Digant and SteveO) will put together a demo video.
[AI] (SteveO) will discuss using a COmanage VM with the Attribute Workshop Program Committee.
[AI] (Digant) will register the Sympa bug in the COmanage JIRA for our reference, and follow up with Sympa developers/maintainers.
[AI] (Digant) will verify that Confluence is working with COmanage
[AI] (Digant) will incorporate the user dashboard that Steven designed into COmanage.
[AI] (Ken) will send an outline to Steven, Tom and Digant as a basis for talking to NSF about collaboration with HUBzero.
[AI] (Ken) will draft an email to interested parties who could be helpful in COmanage testing.
[AI] (Steven and Jim) will flesh out the existing developer domestication guidelines in the wiki.
[AI] (Ken) will ask his contact at the Norwegian Federation about Foodle.
[AI] (Bob) will provide to the list background on user stories.
[AI] (Ken) will talk with Lois about Fluid involvement in improving the COmanage GUI, scheduling it for later in the year.
[AI] (Chris) will contact Atlassian and try to obtain a timetable for Jira domestication. (Ken) will provide some wording for this communication with Atlassian.
[AI] (Bob) will send links to the group on the invitation problem.
[AI] (Ken) will send a note to his contact at OOI to explore their level interest (after the COmanage alpha is ready).
[AI] (Ken) will ping Frank Siebenlist from Argonne National Laboratory, who is interested in COmanage.
Discussion
Internet2 Technical Services Group (TSG) requirements for COmanage production deployment
What is production ready? What would be necessary for COmanage to be a useful tool to deploy within Internet2?
Mike's comments:
Internet2 TSG administers a variety of services for the membership and staff participating in meetings, working groups, SIGs, governance structures, among other things.
Runs two instances of Confluence - one Shibbolized and one not.
Supports over 1400 mailing lists.
As a VO, Internet2 supports a significant user base of people at the various member organizations collaborating on various Internet2-related projects or activities.
It's a challenge to provide secure trusted access to users who do not have federation credentials, other than sending them to a zero LoA IdP such as ProtectNetwork. It's necessary to make many local authorization decisions, across multiple applications.
Internet2 has a 20,000 person MS SQL Server membership database with vendor-specific software running on top of it. The database includes info on many, but not all, of the users who need access to the wiki, mailing lists, etc.
COmanage would offer many advantages - e.g. allow integration with the membership database and provide the infrastructure for single point management of the members of the 1400+ mailing list, two confluence servers, etc.
Concerns:
Looking at COmanage as an appliance, there are concerns about the scalability of Sympa and Confluence in VMware.
Running multiple collaborative applications in a single prepackaged VM makes diagnosis of problems difficult. A bug in one application can affect everything.
The requirement to run Debian is another concern. The current TSG standard is to use in Red Hat Linux.
The appliance would be a good choice for a demo or for a small organization with no or limited internal IT support available, but not for Internet2.
A more appealing model is for Internet2 to consume COmanage from a VO service provider or to become a VO service provider of COmanage. Interne2 could create groups and also delegate to others the ability to create groups.
Q: Suggestion that as a starting point TSG could run the COmanage appliance to support a single project, to become familiar with it and provide feedback to the COmanage developers.
A: This could make sense in a development environment, but probably not in the production environment.
Q: What would the TSG imagine as a first step to seeing COmanage being used by a group, since it's agreed that migrating all of the production Sympa and Confluence services is not practical at this stage?
A: TSG would like an instance of COmanage that provides infrastructure services for managing our membership. It would offer a UI along with Grouper and LDAP, and could be connected to our member database. We could migrate to another version of Sympa underneath that and leverage it for mailing list management. Then if that works, we could move to having an instance of Confluence running with COmanage.
The suggestion was made to initially use COmanage for a group that has a clearly defined and limited duration so we could discard the data at end and not be concerned about migrating it into later versions, which may be challenging given its current Alpha status.
Mike stated that TSG does not want to add and support another instance of LDAP, Grouper, Confluence and Sympa. TSG wants something that moves us towards becoming a scalable VO service provider.
It was observed that the appliance is not currently geared for handling a 20,000 person membership database.
Heather's summary: TSG would be interested in using a COmanage version that runs on Red Hat and works without all applications having to be contained in one server.
TSG will look at the COmanage Alpha version from an end user perspective and provide feedback. Ken stated that this would be helpful, with emphasis on feedback on functionality, not on the GUI.
Ken's Update
UK and JISC are investing more resources into Grouper.
At end of May, a supplemental request was submitted to NSF to continue support for development beyond the end of the current grant. We should hear back in about one month.
The CIC (Committee for Institutional Cooperation) is showing increased interest in COmanage. University Illinois Urbana-Champaign is working on appliance aspects of COmanage. In the future we may choose to shift the CIC efforts from the pure appliance to the COmanage framework and other issues.
SURFnet Involvement
SURFnet has adopted COmanage as a collaboration management platform.
Key points from the 20-May-09 email from SURFnet to Ken and Heather:
SURFnet is interested in working on domestication of applications. They would like practical and technical guidelines on domestication strategies. They suggested creating a set of generic libraries to help in domestication.
In addition to working on application domestication, SURFnet also offered to work on COmanage itself.
SURFnet raised concerns about supporting multiple applications in one VM, just as Mike LaHaye has. They are interested in splitting up components over a number of servers, and especially getting COmanage running on CentOS.
SURFnet recognizes challenges in trying to coordinate development across multiple organizations, especially around the appliance, and suggested that a shared code repository be set up.
SURFnet wants to design an "entrypoint" and would like to introduce a portal, perhaps using something like OpenSocial.
Heather is developing "how you participate with us" documentation.
Ken raised the question: do we all agree on same framework? Is there a risk of divergent frameworks? The space for privilege management in COmanage is unfilled right now.
Heather stated that the framework allows for discrete components. It shouldn't be inherently problematic if SURFnet takes some component down a different path.
If a component such as privilege management leverages expression in LDAP, that will be fine. If a component relies on different core infrastructure, then issues would arise that would need to be discussed.
It was noted that according to the Grouper roadmap, Grouper v1.5 will start to address privilege management. Grouper v1.6 will include a user interface for privilege management.
There are approximately 25 people in SURFnet's middleware group. Internet2 has around 10 FTE total, including grant support for various member campus IT staff members, in the middleware area.
It will make sense in the future to move the COmanage call to earlier in the day to accommodate the Europeans.
It will be beneficial to advance our framework documents prior to meeting with SURFnet, though we will be inviting their input into those frameworks.
A face-to-face meeting would be ideal. Unfortunately, SURFnet representatives are not able to attend CAMP in Philadelphia in June.
[AI] Ken will investigate setting up a video conference meeting with the SURFnet group during CAMP or Advanced CAMP in Philadelphia, June 15-19, 2009.
[AI] Ken will respond to the May 20 email from SURFnet, providing a summary of the discussion about collaborating on various aspects of COmanage.
Ken hopes to get a similar level of commitment to COmanage from the UK folks at the TERENA meeting in Spain the week of June 8.
Opening the COmanage-Dev List
Heather asked if we are now at the point where it makes sense to open up the COmanage-dev list to anyone who wants to subscribe. TomB suggested there is a model for that on the Grouper site.
Next COmanage call is Friday June 12, 2009 at 2:00 p.m. EDT, 11:00 p.m. PDT