1 / 6

Requirements Collection

Streamlining the transition of requirements from VRCs to MCB, outsourcing to MW providers, central DB for tracking, and direct tech specs discussions. EGI acts as dissemination hub and support system facilitator. Event coordination and repositories enhance project efficiency.

dsteiger
Télécharger la présentation

Requirements Collection

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. Requirements Collection • EGI (MCB), VRCs, Middleware (EMI, SGI,DORII) • Requirements go from VCRs to MCB, MCB sets priorities, MCB outsources reqs to MW providers • Tools: Central DB with links to more project-specific tools, maintained to MCB • Unique ID for each requirement • Tech specs discussed directly between interested parties (VCRs and MW providers) • Requirements in general have to go through the MCB, but VRCs can express requirements directly to MW providers, who need to harmonize them with the main priorities • Requirement roadmap has to be visible and monitored using the central DB

  2. Dissemination • EGI.eu acts as a hub for NGIs and SSCs • CUE may have a similar role • GridTalk will be talking will all of the above • Similar role for OSG, GEANT, DEISA/PRACE, ESFRI, etc • Targets: policy makers, funders, EC, general public • Look at the info flow, see if GGUS can be used to pass info rather than mailing lists, consider tracking dissemination requests as user tickets • EGI.eu can act as a support team for dissemination requests • Provide a DB of all produced dissemination material. Where is it? EGI.eu can maintain it

  3. Support Systems and Flow • Application porting support, user support, operation support • GGUS is the backbone • For SSCs (ROSCOE, SAFE), each community will have a dedicated support team in GGUS (2st-level, possibly 3nd level) • SGI: 2nd or 3rd level support (SSCs, EGI act as 1st- and 2nd-level) • EMI: 3rd level support (SSCs, EGI act as 1st-level and 2nd-level) • TAPAS: GGUS not used so far and use of certificates (or emails) quite restrictive, but will look into it • EGI: is there enough effort for doing 1st-level support and triaging for users and applications? What is the role of TPM?

  4. Event Planning/Coordination • Major EGI-related events (EGI User Forum, EGI Conference) • Projects should align their events on these major events and add specific events as they see fit during the project lifetime • Questions whether the EGI Conference is still compelling for other projects, especially applications. May be more relevant to NGIs, operations, MW projects, etc. • Major events to allocate scratch areas for projects to contribute to • Organize a common calendar of events where everything can be made visible (GridTalk) • What about PRACE, Nordunet, OGF, SC, Summer and Winter Computing Schools? • Training schools? Joint events? One full week with common and specialised tracks • Maybe EGI Conferences can become also containers for joint events

  5. Repositories • EGI UMD repository, this should be more a metadata repository with information about apps, services, components, etc, rather than a software repository • EMI software/tests/metrics repository • SGI portlets repository (can be software, can be links) • RESPECT (list of approved apps) • DORII repository contains software packages and documentation • EGI.eu: Dissemination material repository (“knowledge base”) • TAPAS: repository of use cases, piloted by TAPAS and then transferred to EGI later on

  6. Certification Process • EMI: “Works with EMI” program to certify applications with EMI middleware • EGI: UMD (“Works on EGI”, deployment and other acceptance criteria, etc) • RESPECT: user level certification (VRC) • How does this work? Is this a formal process to be followed or useful tools/procedures that software providers may want to follow at their discretion • The different ‘certifications’ may become attributes of the software in the repositories

More Related