REVIEW-22: SDIACT-220 Incremental GenesisII fixes and enhancements - SD&I Test Readiness Review

This is a joint SD&I and Operations readiness review for SDIACT-220 Incremental GenesisII fixes and enhancements. The Genesis II GFFS is a grid middleware application based on Web Service standards (WS-Trust, OGSA-BES, etc). The GFFS implements a rooted file system where resources can be linked in from arbitrary global locations (assuming that a user has appropriate rights on the resources and on the GFFS directory where the links are to be made). The GFFS provides features for “wrapping” heterogeneous clusters and queuing systems into a common model, where users can submit jobs to these systems via a single queue (or via multiple queues partitioned by platform and other characteristics if preferred). SDIACT-220 is both an incremental update and move to a SaaS model.

• (Joe) FYI, a lot of the examples use Mason, which is likely to be retired in ~6 months

Software:

• http://software.xsede.org/development/genesis2/sdiact-220/production_grid

Documentation

• Introduction
  • XSEDE GFFS Quickstart guide
• Design/Security overview
  • Security and General Design Description
  • Operational Security Considerations
• Installation guide
  • https://software.xsede.org/svn/sdi/activities/sdiact-220/trunk/Plans/Service_Provider_Guide.pdf
• Deployment Plan
  • SDIACT-220 Deployment Plan
• User guide
  • GFFS User guide (see Section E)
• Defect, issue, and risk reporting
  • See SDIACT-220 test plan below
• Acceptance test plan
  • Test Plan
• Testing resources
  • hpcdev-pub04.sdsc.edu (CentOS 6) - Galen

Package information: All software packages (e.g., server and client packages) for this CI are listed.

Documentation and Installation instructions: The deployment plan for this CI on XSEDE is clearly described as well as the installation instructions and any XSEDE specific configuration instructions.

Test environment and facilities: The test environment needed to adequately to validate this component is described. Should indicate also whether testing can be performed within a VM and if not, the reasons for it.

Assumptions: Lists any assumptions needed before testing can begin (e.g., accounts needed).

Test procedures, cases, and scenarios: Lists the tests that should be run or an associated test suite and expected performance metrics if applicable.

Defect, issue, and risk reporting: Deployment plans should include defect and issue reporting information. The testing plan could reference that same information from the deployment plan, or provide alternate information if defects and issues need to be reported differently during testing. Risks, as well as defects and issues, should be part of the testing report.