Participant: Bjiorn Hagemeyer, Danilo Dongiovanni, Frantisek Dvorak, Jozef Cernak, Tomasz Wolak, Alberto Aimar, Gianni Pucciani, Anders Waananen, Cristina Aiftimiei, Owen Singer, Jan Schaefer

1. Static Testbed or dynamic Testbeds views and use cases:
  1. static: 1. 1 bdii publishing all resources - 2. 1 bdii for each RELEASE publishing related resources
  2. dynamic: 1. Through an information system configurable on the fly by developers one can allow to personalize testbed sets of resources (selected by developers from a pool of instances deploying production and Release Candidate versions)

AGREEMENT ON: - SA2.6 provides static bdii:

  1. with just production services, reachable from all sites
  2. If needed we will separate RC versions in a different bdii (Owen suggests to wait for this extra effort, until we're sure it is needed)

PTs. for particular test needs can build their own bdii including EMI-TESTBED top bdii resources into their own testbed.

RC defined as: version identified by an official build (in etics or similar). PTs declare when their product is ready to be a RC. SA2.6 is notified. RC is something thought to be suitable for the release, without changes.
Unicore, ARC: similar approach for information system

2. TESTBED STATUS dashboard: implementation of a webpage publishing testbed resources overview including their status (collected from Nagios)
- Not possible to setup a central nagios with ping (DESY has firewall for "ping" for example)
Danilo: AFAIK Two levels nagios is available for grid nagios, which groups hosts by services on the base of bdii information and have no probes for unicore or arc. We need a two levels nagios system with just basic checks (ping/ssh)
ACTION - Tomasz ask for a solution at nagios people and come back with more info about requirements.

3. GGUS shifts for testbeds + 1 person responsible for each site/middleware
- populate the mailing list
ACTION on ALL: - each participating site sends Danilo either a mailing list or >=1 mail accounts.
- Agreement on keeping response time ~2 working days on best effort

4. HW dimensioning and contribution from different partners
- SL5/64b - Deb5 - SL5/32b x 11ARC + 11Unicore + 17gLite
in the testbed now we have 65 servers, with some redundance of services or same service on different platforms.

ACTION on Danilo: PREPARE A TABLE with SERVICES * PLATFORMS * SITES, putting together info in the deliverable with info about the possibility to deploy on same server.

End of October last expected date for EMI 0

5. VO deployment plan - accepted as emitest VO (PEB decision).
- ACTION on DANILO: registering in the CIC portal
- VO in GGUS. we see later if it is needed

6. fake CA management on EMItestbed
- Vincenzo Ciaschini from VOMS PT will try arc instant CA tool (SA2.6 advertize it into the twiki)
- if not enough for VOMS use case, agreement on deploying VOMS PT rpms on CNAF/ CERN testbed.

-- DaniloDongiovanni - 01-Oct-2010

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2010-10-01 - DaniloDongiovanniExternal
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback