Release Cases

The mission of the Middleware Preview Services is, in general, to offer previews of new middleware functionalities to interested users.
More particularly, the middleware previews can be further distinguished into two major classes:

• Previews of client tools (changes/additions affecting Worker Nodes, User Interfaces, VOBOXes)
• Previews of grid services (a.k.a. pilot or experimental services)

This twiki addresses the Pilot Services release procedure.
For client tools release procedure please refer to .....

Pilot Services Release Procedure

In the following we consider three possible phases for a Pilot Service Release:

1. Pilot service Candidature: a Pilot Service deployment request is submitted by some EGEE entity and its deployability is verified within PPS
2. Pilot service deployment in Production
3. Updates for Pilot Sevices which successfully passed phases a) or b)
   
   

Pilot service Proposal

1. Pilot Service official request by some entity (VO,TMB..)
   1. Request: Pilot Request submission to pps-support with a clear description of pilot service required. (SUPPORT Request Submission in savannah, Category Pilot Service)
   2. Appointment of pilot service coordinator among PPS staff in charge of coordinating the pilot_service deployment procedure.
   3. The appointed pilot service coordinator opens a pilot release project in savannah.
   4. Identification of developers team referent in charge of communication for the pilot service deployment test
   5. Pilot Coordinator evaluates Pilot release category: Normal (pre-deployment tests mandatory) or Fast (pre-deployment tests Optional)
   6. Identification of PPS Site Managers in charge of pilot service pre-deployment testing expected to produce a pre-deployment report ( Optional )
2. Pilot service PPS deployment tests: this step is aimed at checking whether Pilot is deployable, write release notes and make the service available at CNAF repository. Pilot service pre-deployment test must report on the following:
   1. Definition of pilot service category among:
      • Backward compatible server update (or New Service)
      • Non-backward compatible server update
   2. Availability of Yaim installation
   3. Availability of proper Installation/Configuration Documentation, including list of patches, dependencies and authorization of SA3 for deployment (possibly with a savannah flag Pilot OK/DENY)
   4. Definition of impact of the pilot on sites: list of services affected by the pilot; HW/SW resources required (This must be provided by developers)
   5. Availability of a Source Repository containing all rpms needed for first installation. This repository is created by developers as an official rpms source of the pilot service. Developers are supposed to update it with proper rpms just before submitting a new CNAF mirroring request.
      • The functionality check of this repository is part of pre-deployment test. The Source Repository must stay untouched once the pre-deployment check starts. The repository functionality test triggers the CNAF mirroring (Same procedure as current PPS releases.
      • The Source repository must have the following structure for each OS branch available (ex. SL4/i386/):
        • RPMS.Release (this contains initial release patch rpms)
        • RPMS.externals (this contains non gLite needed rpms)
        • RPMS.pilot_updates (this is used for pilot new patches deployment)
        • RPMS.production_updates (this is used for production updates deploymen)
   6. Define the IS attribute which will identify pilot resources in the BDII
   7. Write Pilot service release notes

Pilot service Deployment in Production

1. Call for participation in pilot: Pilot service coordinator sends a broadcast to PPS/Production sites to probe sites interest in trying the pilot
2. Actual deployment of Pilot among interested sites
   • Keep track of following information:
     • List of sites involved and accounting of resource provided from each site
     • List of problems encountered in installation/configuration (savannah bugs?)
3. Publication of new resources:
   • • verify publication of resources in the bdii
     • broadcast to egee community
4. Users feedback:

Pilot service Updates

Two update cases:

1. Production updates (security updates, any non specific pilot service; bug fix) are driven by production updates schedule:
   1. These updates go in the RPMS.production updates directory of the source repository (never touched since last mirroring at CNAF). The pilot coordinator starts a production rpms update procedure similar to the updates we currently run in pps.
   2. Pre-deployment test required (Optional)
   3. Update of release note page
   4. Source Repository Mirrored at INFN-CNAF
   5. Broadcast to sites
2. Pilot service updates:
   1. Developers candidate a new update for the pilot service. This occurs when they think to have reached a new stable version of the service fixing bugs.
   2. Pilot coordinator gives the ok for update
   3. RPMS.updates directory at the source repository
   4. Pre-deployment test (Optional)
   5. Update of release note page
   6. CNAF Mirroring
   7. Broadcast to sites