SURAgrid in-person project planning

Thursday & Friday, September 21 & 22

SURA DC office, Conference rooms A/B

1201 New York Ave NW , Washington DC, 20005

Con call attendance: 800-377-8846, 69072307

UArk: Amy Apon, intermittent on Thursday (approx 9 a.m. EDT)

In-person attendees:

Thursday, September 21

• Introductions & agenda review (8:30 – 9)
• Brief history & current status of SURAgrid (9 – 9:30) [See: http://www.sura.org/programs/docs/SURAgridSnapshots-Sep06.ppt ]
• SURA & SURAgrid (9:30 – 10:15) [See: http://www.sura.org/programs/docs/SURAgridOverview-GCraneSept06.ppt ]
• Project Planning (10:30 – 4:45)

• Summary: We shared ideas and perspectives on critical topics of mission & goals, participation, and organizational structure. We spent the bulk of the day on this, resulting in consensus we need to develop and document a community-driven project plan, including more formal structure and increased community involvement for SURAgrid in order to move from our “grass roots” beginnings to a larger and sustainable program, The direct outcome is a “plan to plan” – forming a working group to spearhead creation of a multi-year SURAgrid project plan. See discussion and specific next steps in notes below.

• Other Topics: (4:45 – 5:30)

(See additional notes below)

• CCLI proposal idea, from Barry Wilkinson
• Possibilities for data grid partnership with Avaki, from Jerry Perez
• Update on United Devices activity at GSU, from Art Vandenberg
• Misc other topics: AccessGrid for SURAgrid meetings, Rocks roll for SURAgrid

Group dinner, 6:30 p.m. - Tuscana West, 1350 I Street N.W., Washington, D.C., 202-289-7300, http://www.tuscanawest.net

Friday, September 22

Deployment Fest: Focus use of account management tools (8 a.m. – 12 pm.)

• Presentation from Jim on use of tools [See: http://www.sura.org/programs/docs/SURAgrid-Jokl-20060922.pdf ]
• Usage experience from Brian Brooks at Kennesaw State [See: http://www.sura.org/programs/docs/ksusuratools5.ppt ] and Victor Bolet at GSU
• Free-form time to make individual progress.

Revisit mission/goals (where by next year? where in five years?)

(Moderator: Jill Gemmill, UAB)

Current state: Goals as listed on Web, confirmed informally but explicitly in a few meetings over time. No other documents related to mission, charter, etc.

We revisited our current SURAgrid goals and also developed an accompanying mission statement since we haven’t had one to-date. Black text is from existing material, blue text is new material on which there was consensus, highlighted parts are new material or suggestions requiring additional discussion to arrive at consensus and/or final language.

Mission : Provide collaborative community and a shared grid resource to advance the R&E goals of the SURA region.

SURAgrid goals :

• To provide a scalable grid infrastructure (SURAgrid) for secure access to shared resources across institutional boundaries.
• To promote the use of SURAgrid for the broad research and education community.
• [Serve as a vehicle for outreach and training to the wider community]
• To provide a forum for participating institutions to gain additional experience with grid technology and participate in collaborative project development.
• Facilitate collaboration, interaction, interoperability and integration w/other grids.
• Serve as a capacity, knowledge and policy bridge between campus and national grids.
• Plan for the future evolution of SURAgrid as a sustainable dual-purpose resource [reliable, experimental].
• Add something about serving the “rest of us” (little & medium science, as well as big, and also education, those who have need but are not in the customer set for other grids – SURAgrid for Everyone!

Discussion: (Questions posed in advance of the meeting in black text; notes from meeting in blue)

• Who are the intended users of SURAgrid? Would be useful to document existing apps in the form of user scenarios; develop other illustrative scenarios as needed. (Note: Kate/MFY are working on similar as part of SGER grant for SURAgrid application discovery/deployment.)
• Should goals explicitly address integration/positioning with other grids or is that implied?
• Removed the following from the goals to be addressed as a participation or implementation requirement//objective: “that leverages distributed identity management and authorization while managing…” Discussed further as: What local infrastructure does a university need to participate in SURAgrid? (Central campus CA? Ability to translate from certificate to another?) Need to address policy as well as technology integration. Input on this also needs to go fairly immediately into the planning for a two-tiered PKI. Near-term goal is to accommodate both experimental/production modes in authN/Z – is that the long-term goal? Bring examination of current Teragrid processes into the two-tiered PKI exploration since they are thinking on some of these same issues (scaling authN/Z).
• Recommendation for SURAgrid to provide credentials for those institutions that don’t have it (or can’t use what they have for some reason, at this time)
• Should SURAgrid be in the business of promoting/encouraging (maybe actively educating/facilitating) the maturing of campus ID management? (Connections to work on this may be possible through SURA IT Committee.) Could revisit original CA recommendation to the SURA IT Committee (from original Grid Think meeting) as part of next step authN/Z planning.
• Objective in support of broad use: Develop domain-specific user communities…

Next steps:

We were spending quite a bit of time on this and in danger of getting only this topic covered. So we put a hold on discussion to move on to other topics and see where that would lead us…

Participation (benefits and responsibilities)

(Moderator: MFY, SURA)

Current state: Loosely – participant is anyone contributing expertise, apps or resources. Contact MFY (or MFY/Art) and you’re in. Tracked through various “soft” approaches (SURAgrid call notes, participant list on Web, resource & application tracking by SURA (Kate), resource monitor of portal). No documented policy or procedures for enforcement of policy.

Discussion: (Questions posed in advance of the meeting in black text; notes from meeting in blue)

• August 28th meeting notes on benefits and responsibilities…confirmed desire to be open to levels of participation while also moving towards production. What else?
• Does everyone need to run an app? No. Contribute a resource? No. Attend and participate in meetings Depends on who you are and working groups Depends on who you are?
• When is a site considered “inactive”? Should we define different levels of participation? No consensus on this. Need to look at the type and value of different contributions, also that the value of particular types of contributions and participation are temporal, shifting as necessary in light of the current state of SURAgrid, and to meet SURAgrid goals.
• Are some resources more valuable than others? Some apps? How does this affect benefits and responsibilities of participation?
• Are there individual members or just institutional members (or maybe “sponsored individuals”?)
• Getting in and out of SURAgrid (policy and process: who fields inquiries, who reviews status, who suggests or takes action if needed?)

Much brainstorming on how to slice and dice the issues…

**NOT NECESSARILY A RELATIONSHIP BETWEEN COLUMNS AS WRITTEN!**

Want to have as many ways to participate as possible so that broad community can be involved. What are the benefits to SURAgrid of each type of participation?

Types of participation to enable reaching of goals:

Contribution of production level resources

Contribution of test level resources

Expertise in necessary technologies

Contribution to development/delivery of outreach

Contribution to project planning

Contributions of funding

Contributions of links to communities of interest

Are all forms of participation equal?

Temporal aspects:

• Different contributions are more valuable to SURAgrid at this point in time, will change over time.
• Also, type/amount of contribution may necessarily shift for a site from initial involvement through ongoing participation. How to accommodate different starting points for sites and their transition through “ranks” of contributions.

If we were forced to put something on a Web page today, maybe we’d describe responsibility of participation as:

“Accept a role in the community. Current roles are:” (evaluated at what interval – part of project planning?) roles (and rankings?)

[brainstorming on current roles…]

• Resource provider
• Application user
• Application tester
• Resource tester
• Application provider
• Support provider
• Documenter
• Project planner
• Sugar Daddy/Momma
• Liaison
• Ambassador
• Evangelist
• Training developer or deliverer
• Policy, technology or architecture developer
• Webmaster
• Grid administrator
• Domain expert
• Flywheel [inertial expediter]
• Facilities host [w or w/o cookies]
• Expertise provider
• Visionary

We should also take a look at how other grids are handling this today (their participation levels, org structure to encourage and reinforce types of participation)

Next steps:

Similar to mission/goals discussion, we spent a good deal of time gathering input here but then put a cap on discussion to move to the next topic – becoming clear that we need to address these issues in a more formal way and through a structured process to bring in full group (and other stakeholder?) input.

Organizational structure (how decisions are made, how work gets done)

(Moderator: Victor Bolet, GSU)

Current state: Loose consortium, friendly group J , meetings/agendas established and facilitated by SURA, participation upon request, all participants treated as equals in decision-making but no formal voting, no formal leader (?), working groups formed to get work done, implementation team – mostly volunteer (except SURA and occasional subcontracts) and, if no one volunteers, work doesn’t get done. Communication tools – listservs, Web site, bi-weekly con calls, semi-annual in-person meeting.

Discussion: (Questions posed in advance of the meeting in black text; notes from meeting in blue)

• What sort of organization is SURAgrid (or can it become) and what organizational/governance structure makes sense, now and in the future?
• Do we need a business model? Now? Some other time? (when and how?)
• What organizational areas need to be more formal? What can stay loose or as-is?
• What communication paths/mechanisms are needed?
• Organizational structure should support work in areas necessary to meet goals:
• grid-building, operations & support
• resource admin & support
• application development and support
• outreach
• liaison to other projects and communities
• project planning, management & communication
• funding development

What kinds of structures could we pursue? Do we need to make a change or are we good to go for the next year or so?

Ideas…

• Groups of participants representing the different types of contributions (roles) could be grouped and tasked with planning/progress in applicable areas.
• Establish a structure that incorporates mentoring of new participants by “senior” participants
• Set a participation fee once we have a service that is valuable? Related: How do we understand what is considered valuable? We could learn some of this through survey of current participants to identify highest priority benefits today and anticipated (also consider ratio of type/level of participation to benefits expected/gained). Prioritize project resources and activities to solidify/expand the identified benefits in order to increase value of participation and level of institutional commitment.

What aspects of our current structure do we want to continue/keep?

• Decision by consensus
• Smaller steering mechanisms for structure, but open to participation from interested community members
• Committees to get specific work done.

Related: What are the distinguishing characteristics of SURAgrid?

• Strength of “regional-ness” & SURA organizational structure
• Whatever it is that has enabled us to build what we have today from much less (funding-wise) than other grid initiatives
• Emphasis on inclusion (broad community)
• Support for little and medium, as well as big, science.
• Supporting education [grad, undergrad, K-12] as a grid application.
• Could perhaps be the first to come up with a viable business model for a major grid infrastructure, without relying on agency funds. (Other similar initiatives – e.g., Teragrid, OSG – may be more complacent in this area since they have large amounts of multi-year funding. Without this level of support, we are motivated and positioned to solve this problem!
• Focus on people vs. technology.
• A provider of on-demand resources for SURA region applications?
• Development of a variety of corporate partnerships?
• We are friendly J

An analysis of SURAgrid investment/progress to-date (among institutions, plus SURA investment) to understand the reality of the commitment so far would be useful in making cases for future funding.

Need to have a longer-term vision in mind even to decide what to do next year (five year? Or is three year more appropriate given quickly changing landscape?). Some ideas on framing that…

• If we want to grow in size (double in five years?), does consensus still work? If not, what is the decision making structure?
• If we want to grow the application community (keep general, or create a climate that can also nurture activity in particular domains?), we need to diversity membership to include more application-focused participants.
• If we want to continue to create/sustain current (minimal) level of growth/operations/support along with making progress towards the other goals, we at least need more active working group involvement.
• To build necessary external funding, we need to…?
• To increase the level and quantity of institutional commitment, we need to create an organizational structure that brings direct benefit to grid progress at participating institutions, e.g., installation team for new participants?
• Possible vision: “In five years, we will have a funded distributed Grid Institute for outreach, education & training in grids, with grid resource and application activity being supported by, and also supporting this Institute.”

Multi-lingual SURAgrid materials (e.g. deployment documentation in particular) – This was initially introduced in a not-so-serious mode but then maybe not so crazy given the diversity of SURAgrid participation. Some expressed interest in, and potential volunteerism towards, particular translations: Sandi/UAH & Jerry/TTU for Spanish translation, Mahantesh/Mike/ODU for Indian, Phil/GMU for Chinese.

Next steps:

We determined that it is time to create a top-down, strategy-drive, community driven, multi-year SURAgrid project plan. Create a working group to spearhead this process, open to all interested SURAgrid participants that are able to actively contribute. (Note that working group members should be prepared for active participation vs. attending to see what is going on. All SURAgrid representatives will be informed and have opportunities to provide input at various points throughout the process, including agreement on the final plan.)

Facilitator: Gary Crane, SURA Director of IT Initiatives

Participants:

• SURAgrid volunteers at meeting: MFY, Art Vandenberg, Mike Sachon, Steve Johnson, Jill Gemmill, Sandi Redman, Srikanth Sastry
• Open invitation to rest of SURAgrid community – As announced through these notes to the list and in the next SURAgrid call.
• Possible others from SURA IT community (or beyond?) – Gary Crane checking with SURA IT Steering Group for their recommendations on this.

Other topics

• Barry Wilkinson presented the concept for a CCLI proposal that he and Amy Apon are developing based on their past successful Phase 1 work in this program. They are seeking potential partners in the form of domain science educators ready to integrate instruction in grids into their courses or curriculums. Please contact Barry directly if interested: Barry Wilkinson abw@uncc.edu

• Jerry Perez discussed TTU’s use of Avaki data grid technologies and the possibility for him to promote a SURAgrid partnership with Avaki if there is sufficient interest among SURAgrid participants. We did not arrive at any specific next steps here but MFY offered Jerry the opportunity to present this idea to the group in a future SURAgrid call (so, Jerry, let me know if you want to do that). Anyone with immediate interest should contact Jerry: Jerry Perez < jerry.perez@ttu.edu>

• Art Vandenberg provided an update on GSU activity with United Devices. UD is encouraging GSU to test their Synergy metascheduling product (part of product preview to SURAgrid in vendor presentation via con call on July 10) and Art is interested in exploring that within the larger context of potential utility for SURAgrid. We did not arrive at any immediate next steps but those with interest should contact Art: Art Vandenberg <avandenberg@gsu.edu>.

Puri Bangalore/UAB then let us know that UAB is evaluating the GridWay metascheduler that will eventually be bundled with Globus (see http://www.gridway.org/) He will let us know how it goes.

MFY added Gridway to the list of metaschedulers for compare/contrast once we make it around to this topic again in a SURAgrid call (in a month or two?). This brings the current list to:

• A metascheduler being developed at LSU (per Hartmut Kaiser)
• GRMS ( http://www.gridlab.org/WorkPackages/wp-9/)
• UD Synergy
• Gridway
• Several people also remember UMich having a handle on (developing?) a good metascheduler (so, Shawn, if you are reading this far – could you confirm and send name/pointer if so?)

• Some “on the way out the door” ideas of note:

• Jerry Perez/TTU and David McNabb/UMD put forward the idea of using AccessGrid to enrich or supplement SURAgrid meetings. MFY expressed that SURA doesn’t have resources to plan/lead/support this at this time. However, if there are participants who would like to work on this, it could be an additional (not replacement!) mode for meeting communication. The idea of using the AccessGrid off-week from the regular call schedule was also discussed, as a lower overhead/requirement way to try this out. If anyone wants to pursue this, contact either me, Jerry or David: Jerry Perez < jerry.perez@ttu.edu>, David McNabb <mcnabb@umd.edu>.

• Rocks fans Brian Brooks/KSU, Jerry Perez/TTU, Mahantesh Halappanavar/ODU and Victor Bolet/GSU would like to consider the creation of a SURAgrid "Lite" Roll for Rocks. This could be integrated with account management and support mechanisms to provide a “one-button” approach to deploying resources for those who would prefer that. If you want to endorse this idea, or if you or others at your site would like to work on it, please let this group know of your interest: Brian Brooks <brian.brooks@acm.org>, Mahantesh M Halappanavar <MHalappa@odu.edu>, Jerry Perez < jerry.perez@ttu.edu>, Victor Bolet < vbolet@gsu.edu>,