Final egi model not defined when egee-iii was planned


Download 474 b.
Sana24.04.2017
Hajmi474 b.



Final EGI model not defined when EGEE-III was planned

  • Final EGI model not defined when EGEE-III was planned

    • Task to review work in Year II once final model known
  • Transition to the critical structures required for EGI

    • Start now... find out problems now... not later
  • Our goal: Ensure a smooth transition to the EGI model

    • For our users & resource providers
  • See: EGI Blueprint (http://web.eu-egi.eu/blueprint.pdf)



EGI consists of a central coordinating body EGI.eu:

  • EGI consists of a central coordinating body EGI.eu:

  • Federation of independent National Grid Initiatives

    • Responsible for their own national tasks
    • International tasks interface into EGI operations
  • Global tasks shared between EGI.eu and some NGIs



Remove centralised middleware integration activity

  • Remove centralised middleware integration activity

    • Extend ‘clusters of competence’ to ‘product teams’
    • SA3 & JRA1 working in closer partnership
    • Product teams manage resources to deliver complete results
  • Reduce centralised middleware release mechanism

  • Extend the role of the TMB towards the MCB

    • Monitor the performance of the product teams to deliver software
    • Monitor the operations tool development within SA1
    • Develop the interactions between MU and gLite consortium
      • Effectively SA3 (centre) and the combined JRA1 & SA3 (dist) teams
  • Remove separation between t-infrastructure and production infrastructure





Identify and establish a gLite consortium

  • Identify and establish a gLite consortium

    • Initial consortium identified from JRA1 & SA3 partners
    • Discussion about MoU & technical roadmap for EGI era
  • Establish product teams:

    • Authorisation, VO Management, Security, Information Systems
    • Compute Element, Job Management, L & B, Data
    • Remainder: SA3 specialist partners & SA3 CERN (a.k.a MU)
  • Manage Workplan

    • Integrate core cleanup tasks (documentation, error codes, ...)
    • Group work items into releases
    • Monitor progress of releases
  • Reduce certification workload

    • Group releases onto a node type
    • Generally managed by a single product team


Move from deployment tests to staged rollout

  • Move from deployment tests to staged rollout

    • Deployment tests were very useful in earlier EGEE phases
    • No longer finding a significant number of issues
  • Many NGIs already use staged rollout

    • Sites agree to be the first to deploy new releases
      • Commit to do this within specified time limits
    • Reported experiences used to guide further deployment
      • Can stop or restrict a release if it has issues on certain platforms
  • Monitor progress towards regionalisation

    • Part of Operations Automation Team work
    • Focus on the key services that need to be deployed regionally
  • Change quarterly reporting to country basis

    • Use Country Review template to reflect move to ‘national’ work


T-infrastructure becomes part of the P-infrastructure

  • T-infrastructure becomes part of the P-infrastructure

    • Cannot have people train on something different from production
    • Distinguish environments through the VO mechanisms
  • Use VO mechanism to support training

    • Training specific applications are installed at the site
    • Training specific local services can be installed on a VO box
    • Training specific global services hosted centrally
  • Need to update material to reflect changes



Establish prototype User Forum Steering Committee

  • Establish prototype User Forum Steering Committee

    • Existing NA4 clusters
    • Add in representatives from ‘SSC’ areas:
      • NA3
      • NA2 (Business)
      • SA1 (LHC support)
  • Look to establish science gateways/portals



NA2:

  • NA2:

    • Actively communicate EGI news to EGEE community
    • Encourage regional partners (NGIs) to develop own activities
  • NA5:

    • Encourage policy & standardisation issues within emerging NGIs
  • SA2:

    • Define ENOC operations as NGI Global task




Immediate EGEE activity

  • Immediate EGEE activity

    • Continuing detailed planning of Year II
    • EGEE working with EGI_DS to define D5.5 ‘Transition’ document
  • Next 6 months of EGEE

    • Final EGI model developed and described in proposals
      • EGEE staff contributing experiences into these proposals
    • Refine Year II plans as the proposed EGI model is clarified
  • Final 6 months of EGEE (after 1st October)

    • All activities start to handover activities to EGI proper
      • EGI.eu in place with funding from NGI’s to employ staff
      • Assumes key EGI staff identified and available for employment
    • Refine the EGI model
      • From the experiences gained to date
  • EGEE’09 will be a key point to assess progress



EGEE needs to know which NGIs will join EGI in 2010 in order to progress with the transition planning

  • EGEE needs to know which NGIs will join EGI in 2010 in order to progress with the transition planning

    • First round of NGIs signing MoU in early July
    • These will be asked to bid to host key operational tasks
  • Transition will be greatly simplified if the existing tools are adopted by EGI and the current organisations continue to offer these services

    • Open process as to who hosts the service/tools
    • Any changes will have their own post EGEE transition
  • Maintenance and deployment of middleware in the EGI model requires more planning



Gather list of existing documents to be proposed to EGI as a basis of policies, procedures, processes and user information

  • Gather list of existing documents to be proposed to EGI as a basis of policies, procedures, processes and user information

    • Initial set drawn from many first year deliverables/milestones
    • All activities will review their documents from PM 18
  • Failure to implement EGI transition while maintaining production service

    • The transition over the next 6 months we can manage
    • The transition over the final 6 months has risks
      • Experienced staff may start to leave
      • Mitigation: Front load changes in first 6 months
      • Refine EGI structures based experience during 2nd year of EGEE-III


EGEE is a single integrated project for all aspects

  • EGEE is a single integrated project for all aspects

    • Dissemination
    • Training
    • Applications
    • Middleware development and maintenance
    • Certification and testing
    • Operations
  • EGI will split these into several projects or structures

    • EGI: Operations, Distributed dissemination, middleware maintenance
    • SSCs: Applications, Training, Business dissemination, ...
    • External Projects: Middleware development, certification & testing


EGI proposals are not fully funded

  • EGI proposals are not fully funded

    • EC aware of the issue and have indicated they want a single proposal from the community for EGI and core SSCs
  • The separate middleware proposal is not funded

    • Risk: Reduced (or no) funded maintenance & support effort
      • Impact: Quality of production software deteriorates
      • Mitigation: Include limited maintenance effort in EGI proposal
    • Risk: Reduced (or no) funded development effort
      • Impact: Medium term divergence between of software from user’s needs
      • Mitigation: Strong proposal clearly linked to users’ needs
  • Some of the SSC proposals are not funded

    • Moving towards a single/few proposals with community support
      • Impact: Key functions not supported
      • Mitigation: Move towards a single integrated proposal


EGI structures compromise production quality

  • EGI structures compromise production quality

    • Infrastructure metrics will allow us to see if there is an impact
    • Mitigation: Changes will be incremental and can be backed out
  • EGI Model is under resourced or wrong

    • Similar staffing structures will be established in EGEE Year II
    • Mitigation:
      • A) Before submission – change the structure in the proposal
      • B) After submission – change the final EGI DoW tasks or staffing
  • User communities perceive that EGI will not work

    • That they (or their applications) will not be supported within EGI
    • That the resources they use will no longer be there
    • Mitigation:
      • Increase communication to users on EGI transition status & plans
      • A key focus at EGEE09 for EGEE, EGI_DS and EGI staff


First EGI Council Meeting: 9th July 2009

  • First EGI Council Meeting: 9th July 2009

    • The first set of NGIs will be identified
  • EGEE’09: 21-25th September 2009, Barcelona, Spain

  • Deadline for EGI & related projects: 24th November 2009

    • Proposals for EGI, SSCs and the middleware submitted
  • User Forum 5: 12-16th April 2010, Uppsala, Sweden

    • Planning has already started
  • EGEE-III ends: 30th April 2010



Phase changes in over the next 6 months

  • Phase changes in over the next 6 months

    • Can monitor and refine the steady state over final 6 months
    • Ensure no ‘Big Bang’ in May 2010!
  • NA2 activity increasing communication to users

    • Ensure they are kept informed and forewarned of any changes
  • Transition to EGI is a moving a target

    • EGEE management are involved and engaged in EGI
    • Contribute to EGI model & refine EGEE model during the year
  • Communication between EGEE & EGI projects

    • Cal Loomis: NA4 Activity Manager & SSC Project Coordinator
    • Steven Newhouse: Technical Director & Interim EGI Director


Pursue broader multi-platform support

  • Pursue broader multi-platform support

    • Essential for wider scale deployment of gLite by other groups
  • Continue to document and standardise key interfaces

    • Allow community to select software interface not implementation
  • Understand and attempt to resolve issues around MPI

    • Low uptake of MPI but used by key application communities
  • Development of a gLite Foundation

  • Moving towards a regional/national operational model

    • Assess the tools that need (& can) be migrated
  • Communication of EGI transition to EGEE community

    • Ensure accurate, timely information to all stakeholders


Project

  • Project

    • All activities progressing; all deliverables produced and milestones achieved
    • Consortium working together with all beneficiaries active
    • Financial and effort consumption as foreseen
    • Key project metrics achieved or surpassed
  • Infrastructure & usage

    • Significant increase in number of users from a large diversity of domains
    • Overall CPU usage has more than doubled
    • Improved Quality of Service resulting from better monitoring and application of SLAs
  • Middleware and interoperability

    • Deployed interoperability with other middleware stacks, notably ARC
    • Development of new authorization service
    • Helped drive the ratification of GLUE 2.0 standard by OGF
  • Dissemination, outreach & training

    • 2 major international events organised each with more than 500 participants
    • Very high media profile maintained through the period
    • Training events organised in 29 countries
    • Engagement with ESFRI projects and ERC grantees
  • Sustainability

    • Encouraged the formation of NGIs in over 20 countries thanks to the empowerment of JRUs
    • Laid the foundations for a smooth transfer to the future EGI sustainable structure


NA2: Catherine Gater et al

    • NA2: Catherine Gater et al







































Do'stlaringiz bilan baham:


Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©fayllar.org 2017
ma'muriyatiga murojaat qiling