PPS Pilot Follow-up Meeting Minutes Fri 26 Jun 2009

• Date: Fri 26 Jun 2009
• Agenda: na
• Description: Pilot of glexec/SCAS: mini check-point (restricted to Atlas and LANCASTER)
• Chair: na
• Home: PpsPilotSCAS

Attendance

• PPS: Antonio Retico
• Atlas: Apologise
• LANCASTER: Peter Love

Agenda

• Clarify the situation of the installation at LANCASTER
• Clarification of the versions run by OSG (not covered because Atlas was not represented)
• Green light from Atlas for the release of PATCH:2973 and 2990 (not covered)

Installation at LANCASTER

Peter has installed his site taking the versions from ETICS (http://etics-repository.cern.ch:8080/repository/download/registered/org.glite/ ) because the 64-bit version of glexec wasn't available yet.

The last action done at Lancaster was the installation of

• glite-security-lcas-1.3.11-1
• glite-security-lcas-interface-1.3.11-1

PATCH:3084

Now we are waiting to Atlas to run the scripts again and confirm that the bug is fixed.

Antonio pointed out that although finding the bug was undoubtedly useful, the tests done so far at LANCASTER are not particularly indicative with respect to the release of the patches currently under test in PPS (2973 and 2990). As the activity as progressed so far though it's good to take advantage of them in terms by speeding-up the release of the 64-bit version of glexec (and perhaps SCAS).
This idea is comforted also by the opinion expressed by Massimo an e-mail:

So the advice is for Oscar to "freeze" the version at LANCASTER in a PATCH for 64 bit as soon as the Atlas tests succeed and to release it to certification immediately after (it is premature to release the sw to certification before the functional problems are not sorted out). Once that done, the certification and the activity of Atlas can go on in parallel (as envisaged by Massimo).

In order to maintain the synchronization between the PPS and the certification environment we will use the same release tactic previously adopted and described in the page PpsPilotSCAS#Release_Management . I transcribe the general method for convenience.

1. The Developer (e.g. Oscar at NIKHEF) make a sw change to be distributed in the pilot
2. Oscar describes the changes (rpm versions, ETICS tags, configuration changes new features) in an open patch in state "with provider"
3. Oscar requests the repository manager (Danilo at CNAF) to include the new rpm in the YUM repository giving him the patch as release notes
4. Danilo synchronises the repository and forwards Oscar's message to the sites to upgrade
5. when Oscar and/or the Pilot is satisfied with the level of the new patch, this is moved to certification following the usual process.

In the case of LANCASTER the next changes should be managed as follows (sorry to be tedious):

• A problem is found at LANCASTER
• Oscar or Mischa suggest that e.g. that version lcmaps.l.m.n-1 fixes the problem
• PATCH # NNN is created (or updted if it already exist in status "with provider") with reference to lcmaps.l.m.n-1 (and eventually install documentation)
• Danilo mirrors the content of PATCH #NNN into a GLEXEC-64 yum repository at CNAF an updtates the page PpsPilotSCAS#Installation_Documentation
• Peter upgrades using the yum repository at CNAF followign the instructions in PpsPilotSCAS#Installation_Documentation

Peter said that while supporting the Atlas tests he will start next week to install SCAS (which is not released yet to certification in the 64-bit version).

Antonio stressed that whatever is installed should be taken exclusively from PpsPilotSCAS#Installation_Documentation . If something that is needed isn't there the process described above should be applied.