OSG Facility

1
OSG Facility

• Miron Livny
• OSG Facility Coordinator and PI
• University of Wisconsin-Madison
• Open Science Grid Scientific Advisory Group
  Meeting
• June 12th 2007

2
Structure of the OSG Project
3
The OSG Facility dont

• The OSG Facility does not own any compute
  (processing, storage and communication) resources
• The OSG Facility does not own any middleware
• The OSG Facility does not fund any site or VO
  administration/operation personal

4
The OSG Facility does

• Help sites join the facility and enable effective
  guaranteed and opportunistic usage of their
  resources by remote users
• Help VOs join the facility and enable effective
  guaranteed and opportunistic harnessing of remote
  resources
• Identify (through active engagement) new sites
  and VOs

5
Facility Activities

• Software (UW) provide a software stack that
  meets the needs of OSG sites, OSG VOs and OSG
  operation while supporting interoperability with
  other national and inter-national cyber
  infrastructures
• Integration (UC) Verify, test and evaluate the
  OSG software
• Operation (IU) Coordinate the OSG sites,
  monitor the facility, and maintain and operate
  centralized services
• Security (FNAL) Define and evaluate procedures
  and software stack to prevent un-authorized
  activities and minimize interruption in service
  due to security concerns
• Troubleshooting (UIOWA) help sites and VOs to
  identify and resolve unexpected behavior of the
  OSG software stack
• Engagement (RENCI) Identify VOs and sites that
  can benefit from joining the OSG and hold their
  hand while becoming a productive member of the
  OSG community
• Management (UW) Over all coordination.

6
We are Distributed!

• Sites are distributed
• VOs are distributed
• Team is distributed

7
Facility management

• Each activity has a weekly phone call and posts
  minutes
• Facility activity leaders and Executive Director
  have a weekly phone meeting
• Facility coordinator attends weekly Executive
  Team phone call
• Form ad-hoc cross-activity teams to address
  short-term fires

8
OSG Software Activities

• Package the Virtual Data Toolkit
• Requires local building and testing of all
  components
• Tools for incremental installation
• Tools for verification of configuration
• Tools for functional testing
• Integration of the OSG stack
• Verification Testbed (VTB)
• Integration Testbed (ITB)
• Deployment of the OSG stack
• Build and deploy Pacman caches

9
VDT Stack gt OSG Stack
Input from stakeholders and OSG directors
Test on OSG Validation Testbed
VDT Release
OSG Integration Testbed Release
OSG Production Release
10
Main Software Concerns

• How quickly (and at what FTE cost) can we patch
  the OSG stack and redeploy it?
• Critical for security patches
• Very important for stability and QoS
• How dependable is our software?
• Focus on testing (at all phases), troubleshooting
  of deployed software and careful adoption of new
  software
• Functionality of our software
• Close consultation with stockholders
• Impact on other cyber-infrastructures
• Critical for interoperability

11
(evolving) List of Metrics

• Software support metrics
• of support tickets?
• Amount of discussion on mailing lists
• Average time a ticket is open
• Average time between emails on ticket
• of time supporting different software packages
• Who is submitting tickets (broken down by person,
  VO, etc), how many?

• Software deployment metrics
• of sites using VDT
• of sites part of OSG
• Origin of downloads?
• Versions in use
• Platforms in use
• Which services are deployed at a site?
• How many VOs supported at each site?
• Software development metrics
• How often are releases?
• How many changes occurred in each version?
• How many bugs fixed in each version?
• Activity on source code repository ( of commits)
• of tests run
• of tests that failed
• coverage of tests

12
Review What is the VDT?

• A collection of software
• Grid software (Condor, Globus, VOMS, dCache,
  GUMS, Gratia, and more)
• Virtual Data System (Origin of the name VDT)
• Utilities
• The basis for the OSG software stack
• Mainly configuration settings
• An easy installation
• Goal Push a button, everything just works
• Two methods
• Pacman installs and configures it all
• RPM installs some of the software, no
  configuration
• A support infrastructure

13
Why have the VDT?

• Everyone could download the software from the
  providers
• But the VDT
• Figures out dependencies between software
• Works with providers for bug fixes
• Provides automatic configuration
• Packages it
• Tests everything on 15 platforms (and growing)

14
Software Providers

• The VDT doesnt write software, but gets it from
  providers
• Condor Project
• Globus Alliance
• Globus, MyProxy, GSISSH
• EGEE
• VOMS, CEMon, Fetch-CRL
• OSG Extensions
• Gratia
• Various open source projects
• Apache, MySQL, and many more

15
How much software?
16
Building the VDT

• We support 15 platforms
• Debian 3.1
• Fedora Core 3
• Fedora Core 4 (x86, x86-64)
• Fedora Core 4 (x86-64)
• RedHat Enterprise Linux 3 AS (x86, x86-64, ia64)
• RedHat Enterprise Linux 4 AS (x64, x86-64)
• ROCKS Linux 3.3
• Scientific Linux Fermi 3
• Scientific Linux Fermi 4 (x86, x86-64, ia64)
• SUSE Linux 9 (IA-64)
• We build 35 components on 8 platforms
• Builds are reused on multiple platforms
• Using NMI Build and Test

17
Making a VDT release

• Requires at least one week of testing on VDT
  testbed
• Requires sign-off by OSG Validation Testbed
• Run nightly tests on each supported platform
  until they are clean

18
Some of the Challenges we face

• How should we smoothly update a production
  service?
• In-place vs. on-the-side
• Preserve old configuration while making big
  changes.
• As easy as we try to make it, it still takes
  hours to fully install and set up from scratch
• How do we support more platforms?
• Its a struggle to keep up with the onslaught of
  Linux distributions
• AIX? Mac OS X? Solaris?
• How much effort should we devote to other
  cyber-infrastructures? EGEE, TeraGrid, APAC
• How much effort should we devote to testing?
• We care about interactions between the software
  When using a VOMS proxy with Condor-G, can we
  run a GT4 job with GridFTP transfer, keeping the
  proxy in MyProxy, while using PBS as the backend
  batch system

Fedora Core 6
BCCD