PPS Technical Session Minutes Tue 18 Nov 2008

• Date: Tue 18 Nov 2008
• Agenda: 45261
• Description: SA1 Release Testing: definition of interfaces
• Chair: Antonio Retico

Attendance

• PPS: Antonio Retico
• gLite Release Team: Andreas Unterkircher
• SA1 Release Testing
  • WCSS64 : Franciszek Klajn
  • GUP-CERTIF-TB : Martin Polak
  • PPS-SiGNET : Dejan Lesjak
• CE ROC: Marcin Radecki

Purpose of the meeting

Although the release testing step has formally been in place for some time it has never really worked too well, from the perspective of the glite release process.

In particular in one of the recent release an issue affecting the BDII was found by the CE roc release testing team which didn't get to the gLite release team. The malfunctioning package was then introduced to production. This could have been avoided would a better communication channel have been in place. The purpose of this meeting is to define the two interfaces needed:

• glite Release Team --> SA1 release testing team : a notification of the release has to be sent before the release broadcast is out including a link to a repository from where thesoftware can be downloaded

• SA1 release testing team --> gLite Release team : feedback has to be provided via an appropriate channel.

Relevant points of discussion

Antonio: by default the progress of the release toward production cannot be bound to wait for the completion of the release testing phase. A margin of discretion has to be left to the release manager whether to waitfor these results or not. In fact, from the gLite release perspective, the release testing is specially useful when the update to production is the product of the re-combination of various patches delivered to PPS with different PPS updates. That's the case where oversights in the documentation are more likely to happen. On the contrary, if a limited number of patches goes "peacefully" and in a single bunch from Certification (1st deployment test) to PPS (2nd deployment test) up to production, the level of confidence of the gLite release team will be probably high enough to justify the decision no to wait for the result of the release testing (3rd deployment test). In this case to wait would probably be an unnecessary delay.

gLite release --> SA1 release testing : notification

Antonio: with gLite 3.1 U35 (GGUS:43295) the format of the notification e-mail was changed. A preview of the release notes was given and a link to a temporary repository.

Martin: confirms that he used the provided repository for the update

Antonio: suggests to keep using the notification e-mail for communication. This e-mail (known as the 'Prod-Update E-mail' in the gLite release procedure ;header defined in the template ) is crafted in a way that all replies are logged in a GGUS ticket used to track the release. The ticket is closed by SA1 after the broadcast to production is sent, but updates can still be made after closure. That would suit perfectly the case of a feedback from a release testing team arriving at a random time.

Antonio: the alternative would be to use formal Savannah tasks as it's supposed to happen for all PPS activities. The release testing is something on the boundaries of PPS so we wouldn't mind if tasks were not registered here. The advantage of using formal tasks would be that the process is tracked very closely. A member of the release team would be allowed to say "I won't do it" but the task would however need to be closed.
Marcin: objects that not all the site admins could be allowed to say "I won't do it" and that would cause misunderstandings
Dejan: suggests to try the e-mail approach, then if the need is perceived for a further formalisation, to go for the tasks.

The e-mail approach seems gains the general consensus

SA1 release testing --> gLite release: feedback

Antonio: the media for feedback is the same as above (the 'Prod Update E-mail')

Andreas: I am used to read the test reports in the PPS web. Would the feedback of the release testing be recorded there?
Antonio: no, those reports are produced with a machinery that is part of the PPS release so they are closed after the release to PPS is completed.
P.S. in theory the reports could be updated with the results but their format does not help because they are listed by PPS Update

Antonio asks whether it is possible to define an exact timeline for the performance of the release tests.

• how long do the test take in average?
• are they performed at the sites as high-priority tasks?

Martin: for a standard update 1/2 - 1 day is normally sufficient. The priority however is not defined and there could always been higher priority tasks to be performed first.

Antonio: as we don't have a clear idea of the duration of the test in general the gLite release team cannot assume that not receiving reports form the release testing team means that the release is OK.
Therefore, in order to support the gLite release team in its decision to wait or not, when a site admin starts installing the release he/she should notify us by replying to the 'Prod-Update E-mail' and then reply again with the feedback.
Marcin: that sounds reasonable

Antonio: it's better to write the link to the temporary repository in a dedicated web page. because in principle we don't want everybody to start using it

Antonio for a better visualisation of the history in GGUS it is better to remove the previous messages when replying to the 'Prod-Update E-mail' (just follow the suggestions in the e-mail)

Decisions

1. The 'Prod-Update E-mail' is used as unique communication channel
   • notification of new release and link to preview documentation
   • feedback (tracked in GGUS)
2. The link to the temporary repository will be provided in a web page known to the members of the release testing team for the next releases
3. when the test starts a notification is sent by the release test team member ('Prod-Update E-mail')

AOB

The content of the PPS activity panel with the commitments of the sites member of the relase testing team is reviewed and confirmed correct

The next release will not contain patches that the release testing team can currently test

Notes:

---