COmanage Developers List

[Emily Eisbruch <>]

COmanage Call 23-July-2010

*Attending*

Heather Flanagan, Independent (chair)
Ken Klingenstein, Internet2

Bob Morgan, U. Washington

Benn Oshrin, Internet2
Steven Carmody, Brown 
Chris Hubing, Pennsylvania State U.
Jim Leous, Pennsylvania State U.

Dan Pritts, Internet2

Ann West, Internet2
Renee Frost, Internet2
Steve Olshansky, Internet2
Emily Eisbruch, Internet2, scribe

*New Action Items*

[AI] (Benn) will start a discussion on the list about standards and terminology and begin to develop a glossary on the wiki.

https://spaces.internet2.edu/display/COmanage/Glossary

[AI] (Heather and SteveO) will work on updating the COmanage website and wiki.

*Carry Over Action Items*

[AI] (SteveO) will follow up with Ken about email list structure.  

[AI] (Ken) will develop a COmanage Service Manager job description.

[AI] (Ken) will email the group a COmanage entrance interview/survey for a VO.

[AI] (Steven and Benn) will continue to work on demo development. 

[AI] (Ken) will initiate discussion with UK around collaboration platform work.

[AI] (Heather) will raise the VO Cookbook issue on the upcoming International Collaboration Call. 

[AI] (Jim) will send the group screenshots of the Penn State Confluence dashboard. 

[AI] (Benn, Jim, Chris, Steven) will discuss what's needed to move ahead with the Women's Earth Science Network VO. Status as of 23-July-2010: a conference call is being planned  

DISCUSSION

 

*Vision and Strategy Discussion*

 Benn reviewed his slides presenting an overview of COmanage vision and strategy.

https://spaces.internet2.edu/display/COmanage/Presentations

Comments:

• Heather noted the slides will be very helpful as we start to form technical teams with large VOs.

• Ken liked the slides very much. Ken said the term “collaboration management platforms” is better than the term “VOMS” due to historical use of the term VOMS in the grid community. Ken sent these links 

http://www.globus.org/grid_software/security/voms.php

http://edg-wp2.web.cern.ch/edg-wp2/security/voms/voms.html

• Bob noted that when COmanage was first envisioned, the term VO was intentionally not used, so he agrees that we should not use the term VOMS. We should stick with the “CO” term.

• Danno suggested using the term console instead of “Frontend”

Benn stated that he is happy to rename any elements in the slides. He suggested that a dictionary of terminology would be useful.

[AI] (Benn) will start a discussion on the list about standards and terminology and begin to develop a glossary on the wiki.

https://spaces.internet2.edu/display/COmanage/Glossary

Benn suggested that the COmanage wiki and website should be updated to reflect the Vision and Strategy slides.

[AI] (Heather and SteveO) will work on updating the COmanage website and wiki.

Benn noted that concerning the Next Steps outlined in the slides, it will be useful to assign people to the tasks in the near future.  

Benn has started moving items into JIRA. He is using the key of “CO” instead of the previous key of “CMG.”

https://bugs.internet2.edu/jira/browse/CO

Benn believes that the COmanage logo should be fixed so that the gears can move.

*Demo*

A question was raised about Ken’s demo at the GENI meeting in San Diego in July. Ken was no longer on the call, but it was reported that the federated COmanage demo was not complete for the GENI meeting. Ken may have presented COmanage slides; a report on this could be a topic for him on a future call.

*Registry of Domesticated Applications*

Heather and Benn requested feedback on ways to classify levels of domestication within a registry of domesticated applications:

https://spaces.internet2.edu/display/COmanage/Registry+of+Domesticated+Applications

The initial idea was to define 6 different levels of domestication:

Level 5 - planning stages only or not useful = blackbox, internal, not provisionable

Level 4 - purely internal = internal, provisionable

Level 3 - LDAP, not federated

Level 2 - Not standards compliant but offers a local aspect or hook that could be federated; community contribution plug-in = external, unsupported

Level 1a - Out of the box works with standard federated technologies, needs simple configuration without writing code = external, supported, federated
Level 1b - external, supported, some additional work needed

Danno commented that some of the info in the levels does not lend itself to scaling. For example, clearly Level 5 is less domesticatable than Level 1 . But between levels 3 and 2, it is not clear which is more domesticatable. 

Heather stated that the idea of numbers was to add up numbers to come up with an metric, where the lower the number the better. A solution could be to use more of the 1a and 1b approach when it’s not clear that one domestication level is better than another.

Danno remarked that it’s important to remember that when a new version of a domesticated application comes out, it may not longer be domesticatable. For example, when there is a connector or plug-in that doesn’t come from the vendor or open source project, it might not work when a new version is released.

It was suggested that maybe the best categories are

- Fully domesticatable

- Partially domesticatable

- Not at all domesticatable as currently instantiated

Bob stated that “built-in support for SAML” is not necessarily the ideal. The best scenario is for applications to have hooks so developers can do what they want externally.  Benn noted that some organizations may not want to customize, but may be looking for an out-of-the-box solution.

Benn suggested there are three categories for domestication, and it’s useful to distinguish between the three:

1. There is the ability to write “glue code” for domestication and/or this is required, because all that’s provided by the application is hooks
2. There is some 3rd party support for domestication, could be open source or from a vendor 
3. The application has vendor supported domestication

Heather noted that LIGO is interested in knowing how much code they will need to write to achieve domestication for an application.

After the call, the wiki page was updated to show these levels of domestication:

Level 0 - Not externalizable, not provisionable via automated tools (black box)

• Not considered domesticated.

Level 1 - Not externalizable, but provisionable via automated tools

• Not considered domesticated. e.g. for authn, this would imply passwords stored locally.

Level 2 - Externalizable via hooks

• Considered domesticatable.

Level 3 - Externalizable via third-party plugin

• Considered domesticated for available plugins.

Level 4 - Externalizable via vendor supported functionality

• Considered domesticated for supported functionality.

 

Heather encouraged others to contribute ideas on the wiki.

Next Call: Friday, August 6 at 2pm ET

Emily Eisbruch, Technology Transfer Analyst

Internet2

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

Visit our website: www.internet2.edu
Follow us on Twitter: www.twitter.com/internet2
Become a Fan on Facebook: www.internet2.edu/facebook