1. US LHC OSG Technology Roadmap May 4-5th, 2005 Welcome. Thank you to Deirdre for the arrangements

2. Context The purpose of this meeting is to discuss the Baseline Services for US ATLAS and US CMS use of the Open Science Grid. The output of this meeting will be given to the OSG Technical Groups and Activities to inform and help lead the OSG wide roadmap. Welcome to members of the LCG Baseline Services Working Group.

3. Agenda US CMS and US ATLAS Goals and Status: –Roadmap for US LHC Software and Computing. US LHC Baseline Services on OSG –With emphasis on common requirements across US ATLAS and US CMS. –How are Core Services defined, agreed to, promulgated for OSG?Sufficient, Required, Recommended, Encouraged –Grid-wide, VO-wide.. Baseline Services and Plans for LCG.

4. Output from Parallel Sessions Learn and inform from OSG experience to date: –Ways in which the Deployment Plan lack detail or hinder implementation –Examples of where the Blueprint informs or confuses and needed edits. –Teachings from integration and deployment of signficant new service, Privilege Short term work list for US LHC use of deployed OSG infrastructure over next 4-6 months –Including interoperability with LCG –Including understanding impact and role of emerging EGEE and gLITE services? Medium to longer term program of work needed for US LHC over next 12-24 months.

5. Parallel Sessions - are they the right ones? Workload Management –Job installation and configuration –Job tracking and bookkeeping –Job execution environment, including data access –Policy application –Resource usage accounting and auditing Data Services –Data access - local and remote, grid wide, site side, farm wide, local to job execution. –Data movement - –Role of Reliable File Transfer services ? –Data management and Namespaces

6. Parallel Sessions - are they the right ones? Policy, Security and VO Services –Policy requirements and ideas for OSG short term and medium term –List issues with VOMS –List issues with proxy generation Information, Monitoring and Accounting Services –How do the basket of options play together? –Is there “a” set or “the” set –Important metrics for OSG use.

7. Core Services in Open Science Grid Informed by the principles in the Blueprint. Availability defined through Deployment Plan and Releases. Not all Core Services are required to be provided by a Resource Provider nor used by a VO. US ATLAS and US CMS have a required set of Core Services today. Baseline Services include that set and any extensions needed to support the US ATLAS and US CMS software and computing milestones.

8. Core Services in OSG 0.2 Deployment Compute Elements (CE) Gatekeeper with GT2.4 GRAM compatible interface Storage Elements (SE) A SRM v1.1 compatible interface Resource and Service Discovery –Using Clarens (and GridCAT) Virtual Organization Membership Management –VOMS server for each VO. OSG Operations –Interfaces and Workflow for Ticketing System and distributed Support Center s

9. Access to Batch System based Processing Service Gatekeeper with GT2.4 GRAM compatible interface Monitoring interface(s) ? Authorization via Gridmapfiles or Authorization Services. Sites may use GUMS for dynamic mapping of user PKI certificates to local accounts, invoked from the site gatekeeper. Sites may adapt SAZ to impose site authorization and access policies. VOs are expected to implement policies to prevent overload of the headnodes. Resource allocation policy will be enforced through batch queue priorities as for Grid3.

10. Access to Data Storage Services through SRM V1.1 Compatible interface GridFTP

11. Monitoring Services Monitoring through the use of Ganglia, MonaLisa and MDS. The GridCat service will be used to publish the status of and information of all the sites on the Grid.

12. Processing and Storage Authorization Services site application of authorization and prioritization for processing and storage facilities will be supported for roles and groups within a Virtual Organization (VO). Simple identity and VO role based authorization and prioritization will be provided for processing and storage facilities. For processing this is through use of the Globus Gatekeeper callout. For storage is will be through the SRM callout. VOMS will continue to be used as the repository to map users to VOs.

13. Integration Workshop, 2/05

14. Questions Are there core Monitoring Services required to be provided by a Resource Provider? What is the Execution Environment available to Jobs on Worker Nodes? What Information needs to be published by a Resource - CE or SE?

15. Policy Do VOs need access to Policies describing the accessible resources or is it “try and find out”. VOs say to make effective use of a heterogeneous infrastructure they need to be able to determine policy. –Ie they won’t use OSG if this is not there. CMS Policy Web page http://uscms.org/SoftwareComputing/Grid/Policy/index.php http://uscms.org/SoftwareComputing/Grid/Policy/index.php UofC Policy Web page http://griodine.uchicago.edu/~cldumitr/data/up.status.latest.up.ni cer.txthttp://griodine.uchicago.edu/~cldumitr/data/up.status.latest.up.ni cer.txt (http://griodine.uchicago.edu/~cldumitr/) Will market place ensure policies are provided? Role of OSG contributors to recommend, encourage, guide –Just because services are not required does not lesson the effort and coordination needed to provide them.