1 / 9

WLCG – Worldwide LHC Computing Grid

WLCG – Worldwide LHC Computing Grid. Proposal for Future VO Testing of Middleware Services WLCG Service Reliability Workshop November 27 th 2007. The Problem.

jethro
Télécharger la présentation

WLCG – Worldwide LHC Computing Grid

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. WLCG – Worldwide LHC Computing Grid Proposal for Future VO Testing of Middleware Services WLCG Service ReliabilityWorkshop November 27th 2007

  2. The Problem • VOs with complex use cases and highly developed workflow management can't easily switch between the two infrastructures (production and PPS). This makes it currently very difficult for them to test new clients and services. • How can we do things differently to alleviate this?

  3. The Proposal • In the following slides I present a first proposal to the WLCG experiments for the resolution of the problem. • The proposal is intended to stimulate discussion with the eventual (but not too distant) aim of reaching an agreement that suits us all • Unlikely that the agreement will be reached today, so consider this the kick-off

  4. Functionality Testing • The functionality testing of Clients and Services most probably need to be handled differently to one another • Scenario 1: The fully backward compatible client upgrade • This is the most simple and frequent use case. • New clients will be distributed to production and PPS sites as certificate testing starts. They will be put into the dteam software area so any experiment wishing to test them can source the client from there. • Tags in the Information System will show which sites have the new clients available. • The remainder of the software release process as business as usual.

  5. Functionality Testing • Scenario 2: For VOs that need to test new functionality of clients that only become effective when using recent versions of services (for example bulk operations or session reuse) • We use a small number of upgraded service endpoints in the production service • Discovery is through a specific, dedicated top level BDII • Most of the production services are still visible to the user

  6. Functionality Testing • Scenario 3: Minor changes to services • Business as usual here • The decision of whether a change is minor or not will be made initially by the grid middleware teams

  7. Functionality Testing • Scenario 4: Major/Critical service changes and New services • These will be triggered by the experiments • Testing will be carried out through a pilot service within the PPS. • The pilot services will be populated on demand with the replicated state of a production service • The setup is published in a dedicated BDII which creates the appropriate "view"

  8. Service Stress Testing • Stress testing is difficult to handle by a common process. Here we will work with the VOs one by one, service by service. A suggested process might look something like the following: • These will be triggered by the experiments • Pilot services are set up at one (or small number) of production sites • The pilot services are excluded from the standard production top level BDII and discovery is through a dedicated

  9. What’s missing… • Environment string to identify client version and site used for a particular test (see scenario 1) • We need to extend the filter functionality of the BDII (this is almost ready). • A number of BDIIs need to be set up (~5). They don't need to be very beefy machines. • A procedure to track the certification / documentation / deployment of a “Pilot” patch

More Related