WLCG Workshop, Copenhagen, November 11-12, 2013

Agenda

https://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=251191

Run 2 Scene

Physics at Run 2 - Jorgen Beck Hansen (NBI)

See slides.

Several indications that new physics may be at 9 TeV scale: not for the short term at LHC...

• Run2 will allow access to the 1 TeV scale
• Run2 will be marked by precision studies and search for small deviations

Current Run2 roadmap: 3 years of operations after LS1, including a few months of commissionning

• Expected to restart at 6.5 Tev with 25 ns spacing, nominal luminosity (1.7e34), increasing to 7 TeV according to magnet training
  • Also a risk to go back to 6 or 6.25 TeV...
• Increased pile-up : ~49
• Between 75 and 100 fb-1 expected at the end of Run2
• x10 in luminosity ~ x2 in energy
  • Process dependent

LHC at Run 2 will be a good Higgs factory

• 5.5M Higgs event expected: 100K needed for precision measurements
• Currently ATLAS+CMS: 1400 Higgs events
• Precision of 150 MeV achievable on Higgs mass with 100 fb-1
• Hope to establish a 5 sigma observation in the fermion decay: critical to assess exact Higgs behaviour compared to SM predictions

Dirk: risk of more people concentrating on the same data for precision measurements if no NP discovery is expected?

• JBH: no, no increase of the number of people involved in precision measurements really expected, already a lot! But more data and people wanted to analyse all of them

Computing Model Evolution - I. Fisk

Many things remains stable since the beginning of the project despit a few adjustments: full mesh, data federation...

• in particular the x86 architecture is still here, basic service architecture has not changed

June 2010 workshop: concentrating on increasing flexibility and reducing site boundaries, increasing efficiency of data access for analysis

• No worries about new architectures, clouds...

Flexibility and site boundaries

• Separation of archives and disks means there is no longer a 1-to-1 mapping in T1
  • How many archives do we really need?
  • Difference between T1 and T2 is no longer long term archival: more about support and availability
• T1 and T0 difference also being reduced: CMS plans to do half of the prompt reconstruction at T1s
  • Tested by CMS with parked data from last year
  • Main issue is not performance but availability: a failing T1 may impact the convergence of the system
• Wide area access to data demonstrated to be sustainable for analysis: input small compared to processing time
  • Intelligent I/O and fast networks helped
  • With upcoming 100 GB/s links (first one started between CERN and Budapest), not much difference between local and WAN access
• T1 and T2 functional difference will become very small
• Based on CMS experience, a very large storage capacity at a T1 (1 PB or more) has generally an I/O serving capacity higher than the computing capacity located locally
• WAN access to data will require network information to be available in the resource provisionning system

Resource provisionning has not changed fundamentaly so far but may not be the case in the future

• So far changes was more in the way experiments were using the services
• Clouds may change the game: no more CE/batch but direct provisionning of VMs by pilot infrastructures
  • • Also ability to request a group of machine for a periods of time, potentially long: sites expected to reclaim resources if needed
    • No specific setup required by the site: environment tailored to experiment needs through CVMFS local mounts
• ATLAS and CMS already gained some significant cloud experience with their HLT farms during LS1
• Opening the path to usage of opportunistic resources: cloud APIs or SSH to batch systems
  • Sometimes resources available only a few hours per day but can be on very large facilities like leadership class super-computers
  • Allow to explore things that cannot be done on the pledged resources
• Result: increasing complexity of the resource provisionning layer in experiment frameworks
  • Also potentially common to all experiments
• Also impact the information system to allow advertizing efficiently, without too much effort from the site, transient resources: ultimate goal is to grab every opportunistic resources as they appear, without weeks/days of validation

Multi-core

• GEANT 4.10 has the capability for event-level parallelism
• Several experiments working on threaded frameworks
• CMS believes pilots are the best way to transition smoothly to multi-core: a pilot receives several cores and makes the most efficient possible use, scheduling the appropriate mix of single threaded and multithreaded jobs

New HW architectures will make it as soon as there is a use case where they bring a significant perf improvement (x10 or more) for a given task

• Will probably be dedicated HW for dedicated tasks, releasing general-purpose resources for other tasks
• An experiment may decide to run a particular workflow at just one location with the appropriate resources
• Need to keep in mind that most of our costs is in operations rather than in HW, thus the need for a significant perf factor
• Also take into account the very long lifecycle of SW development in HEP: doesn't make easy optimizations specific to a particular HW

Dirk: risk of funding agencies reducing their efforts with the optimization proposed?

• IF: clearly the current model has a lot of value but funding agencies should be able to understand that the proposed optimizations allow a better usage of the money spent
• I. Bird: the real problem is not funding agencies, this is that sites (in particular T1s) should not reduce they effort if they no longer provide a particular resource (e.g. tape) but keep the same level of effort with some equivalence between the different kind of resources (e.g. less tapes but an improved network connection for serving WAN access)

Stress testing new data access models

• CMS is working on tests that could be repeated over time: having a permanent load helps to stress test the system
• Ueda: ATLAS is planning a DC14
• To be coordinated by Ops Coord

Storage Management/Data Access Evolution - W. Bhimji

FTS3 now in production: gridftp session reuse and htpp/xroot ready to be used

• gridftp redirection is also now implemented in many storage implementations (e.g. EOS, DPM coming soon)

LFC: all experiments moving away

• ATLAS: linked to Ruccio migration

Data federations

• Do we track managed vs. opportunistic access as stated in the TEG
  • CMS is going for totally location independent (AAA)
• http usage promising/growing: more during Run2
• Not much experience yet with caches
  • Many technical issues: how to manage them? Popularity? requirement for authenticated access to data...

Big data: no a hot topic, HEP is no longer unique

• Other communities have others but overlapping requirements
  • Google's Dremel conceptually similar to ROOT...
• Need organizational and technical contacts with other communities
  • Do we need to organize an HEP Big Data event? GridPP started such an initiative, extend it?

Storage management: management protocol needed in addition to access protocols but not necessarily SRM

• For disk only systems, very little of SRM used
• Already some experiences with non-SRM storageu
• New filesystem technologies: CEPH, HDFS, LUSTRE, GPFS
  • Still have somme specific requirements for accounting and security for example
  • Our HEP layer is adapting to these new technologies
• Underestimated cloud storage impact: S3, object stores

• • Using them will require relaxed requirements for security (world readable) and consistency

Need to better understand our I/O requirements: rich data set available from xrootd monitoring, enabling profiling activities

• Keep in mind that organizational issues can have a large impact (imply unanticipated changes) to I/O profile, E.g. analysis models

Site/experiment interactions are critical for HEP storage: will it remain so in the future?

Storage HW driven by the big data market: no major technology evolution expected in the next 5 years

Our current perf is good but is it good enough for the I/O challenge ahead of us in a tight funding situation?

• Balance not clear between improving/optimizing the perf for one application/user or only for the overall systems made of many users doing analysis at the same time

Computing Services Evolution - U. Schwinckerath

Multi-core job support: motivated by the need to improve memory requirements

• Started in 2011 with some whole-node scheduling at CERN but worries about the efficient use of large number of cores
  • Virtualization to provide appropriately sized WNs
  • Job pilot: how to let them know the number of allocated cores. Job features proposal.
  • Impact on job scheduling by batch systems

Machine/job features: old proposal by the HEPiX Virtualization WG, now followed-up by Ops Coord dedicated TF

• Can also be used for other informations like machine life time
• Already deployed at several sites with different batch schedulers

(private) clouds: many challenges

• First level of simplification achievable by putting a batch system on top of an IaaS infrastructure rather than physical+virtual WNs in //
• A greater simplification would be possible if removing the need for a batch system
  • Also removing the scalability pressure on batch systems when converting physical nodes to multiple VMs with a lower core count
  • May need to keep a batch system entry point for non LHC VOs...
• Performance challenges: still some penalty for I/O but very much related to the local infrastructure
• Resource sharing: currently only fixed quotas, i.e. dedicated resources
  • Quotas can only be managed by site/cloud admins
  • Unused part of the quota cannot be given temporarily to another group
  • Optimization is difficult due to the absence of request queues in a cloud. No trivial solution.
  • Vacuum approach: sites responsible to decide which VM to launch but requires tighter interaction between sites and experiments
  • Resource reclamation: could be advertized through machine/job features but how to trig it in absence of request queue?
  • Economic models: not clear how they can apply, no know activity around it
• Scheduling of complex services with dependencies: several solutions like OpenStack HEAT or SlipStream (used in Helix Nebula)
• Accounting: impossible to get HS06 perf of VM in public clouds but some possibilities on private/community clouds
• CMS and ATLAS have now a significant cloud experience on their HLT farms
• Common authentication/authorization between clouds as currently done between grid sites
  • Identity federations?

Experiment Sessions

LHCb

During Run2, LHCb will run at the same luminosity as in 2012

• half the pileup if 25 ns spacing
• Increased trigger rate leading to the same computing requirements

Changes in the processing model in 2012 due to the doubling of integrated luminosity

• Allow reconstruction to occur at selected T2s
• Only do a first pass reconstruction on 30% of the raw data (quality control, calibration, discovery physics)
• Full bandwith data reconstruction in 2-4 delays: avoid end-of-year reprocessing campaign

In 2015, suppression of reprocessing campaign

• HTL1 in real time
• HLT2 deffered by several hours to use the calibration constants computed during HTL1
• further, restripping but no reprocessing

Increased trigger rate put pressure on storage

• Reduced archival to overcome tape storage
• Disk at T2s to overcome the disk storage (T2D)
  • A T2D almost functionnaly equivalent to a T1...
• Data format: strong drive to microDST, transpartent to users through the use of the analysis framework
• Data placement driven by free space available at site but dynamic

Data popularity: LHCb started to collect data last year, currently processing manually

• Plan to move to an automatic processing of popularity data, with ability to trigger deletion if in shortage of space

No major change expected in 2015 but certainly further adaptations.

LHCb Operations

• 1 stripping campaign going on (Fall 2013), 2 more foreseen in 2014
  • High stress on tape systems to stage in datasets reconstructed in 2011/12
• T2Ds: first 5 sites in production, ramping up
  • DPM sites: need the fix currently being developed to fix Xrootd TURL returned by SRM
  • 300 TB minimum per site: want to stay with a limited number of T2s with large resources
• Monitoring: LHCb DIRAC able to feed information about LHCb workloads into the WLCG consolidated monitoring system
  • In the future, will also be able to consume information collected by WLCG monitoring, e.g. perfSonar
• Site Status Board resurrected
• Email list set up for discussing specific T2s issues, mainly T2Ds
  • Main communication channel with sites is the bi-weekly operations meeting
• SL6: most workflows will be submitted to SL6 by default, SL6 builds starting January 2014
• WMS decommissionning: ~10% of sites (~20) still to be moved to direct submission
• FTS3 used in production for all WAN transfers
  • CERN instance, RAL as a backup
• Replica catalogs: planning to move DIRAC File Catalog: lighter and more features ("du", metadata queries)
• WAN access: all sites requested to provide an Xrootd access point
  • Xrootd will be the only access protocol used, gridftp only for transfers
  • May look at http in the future (next year?)
  • Used for failover in case of a problem with the local replica: integrated into Gaudi, commissionning in progress

Opportunistic use of computing resources

• HTL farm (16K cores): not virtualized, node allocation controlled by the PVSS Control Manager
• Several clouds: OpenStack@CERN, OpenNebula@PIC
  • Soon: StratusLab@RAL, OpenStack@Imperial...
• Vac(uum) (Manchester): based on the volunteer computing ideas/paradygm
  • VMs pop up and join DIRAC
• BOINC: LHC@Home Beauty
• For using institutional clouds, need some sort of implementations of target shares
  • Like Vac...
• Clouds bring a lot of flexibility for the VO at the price of becoming sysadmins rather than just users...
• Job masonry is another approach optimizing the overall resource usage: not only for clouds
• Would be great to have a common marketplace for all the clouds we use
• Is CERNVM the official WLCG image? Or just another one...

CMS

Disk/tape separation: T1 sites requested to provide a different endpoint (or namespace behing the same endpoint) for each and PHEDEX managing the migration between both

• Protects against side effect of chaotic analysis: no tape staging triggered by disk access
• Tape staging centrally managed and scheduled
  • Also allows to retrieve a file from another disk replica if any rather than staging it from tape
• Ability to serve different disk endpoints at different locations from the same archive endpoint: increased processing efficiency
  • Also ability to write job output to an "arbitrary archive", not just the one co-located with the disk instance
• CMS in control of what is in disk space according to its own needs
• Data federation will still increase the ability to process data at an arbitrary location, not only the one directly managed by PHEDEX for pre-placement
• Site concerns (initially) about waste of space (duplication between disk and tape instance): should not have a big impact as the disk buffer in front of tapes should be small
• Still minor issues to fix, stress testing planned in 2014
  • Most T1 sites either done or in-progress
• CMS aiming auto-approval of disk subscription and deletion: need to assess the impact on tracking free space
  • Normally information known to PHEDEX + pledges
• Tape families will no longer be required by CMS
• Evolution of site readiness to test disk <-> tape availability

Dynamic data placement, based on ATLAS ideas

• Users associated with sites
• Currently managed space divided into several subsets after agreement with the site data manager
  • Manpower intensive
  • Also some unmanaged space under control of local users that must remain in the limit of site capabilities
• Want to remove space management by physics groups and simplify operations: 60% of T2 disk space managed centrally, 40% regionally or locally (user space)
  • Popularity service is the central piece of the proposed model, allowing for automation in space management
  • Popularity service will enable automatic cache management: automatic removal of no longer used replica, automatic addition of new replica for most popular replica, site usage (CPU and disk) taken into account when adding a replica

AAA data federation

• Based on a hierarchy of redirectors, access authenticated
  • Requires a global namespace that was already there for CMS
• Good CPU efficiency with remote access, even if lower than with local access: 86% vs. 92%
• Used for failover in case of errors opening a file
  • Allow to use CPUs at a T2 with broken storage
  • Enabled by modifications of 2 lines in the site configuration
• Also enable migration of jobs between sites and opportunistic computing resource usage
• Throttling mechanism available to prevent DoS attacks through AAA
• Currently 39/52 sites in AAA, ~95% of T2 datasets available in AAA... want to reach 100%!
• In principle failover could be achieved without a redirector using PHEDEX but will not scale the number of jobs run by CMS
  • Xrootd redirector designed for scaling

ATLAS

Main challenges for computing in Run2

• Flat budgets: means low increase of HW resources year over year (20% CPU, 15% disk)
• New HW architectures emerging

ATLAS computing model evolved since the beginning of data taking from static pre-placement of data with jobs scheduled close to the data to dynamic data placement based on popularity and ability to use free CPU resources wherever they are

• No more multi-hop transfers: direct T2 connection to data sources
• Data popularity currently manually processed to trigger deletion but will move to fully automated deletion

Network technology continuing to evolve and need to explore how to use new features like SDN

Event service currently being developed in ATLAS: allow event per event processing scheduling for better backfilling of available resources

Most important limitations of today infrastructure and solutions

• Difficulties of accomodating new technologies: replacement of DQ2 by Rucio, ProdSys-2 (PanDA+JEDI+Deft)
  • Rucio: file level operations, storage and network optimization in replication strategies
• Memory increase for MC pileup digitization and reconstruction: AthenaMP, parallelism, code speedup
• Multiple data format for analysis: trying to converge on a new analysis format, xAOD

Data processing evolution

• Ability to use T1s for first pass reconstruction when in shortage of resources at T0
• T2s used for the most demanding workflows (high memory or IO intensive tasks), also for data reprocessing and MC simulation
• Will keep the reprocessing campaign at the end of each year but AOD2AOD reprocessing in the interval
• Based on data popularity, no guarantee that one replica will remain on disk for data not accessed
  • Further stagein from tape through central tools
• Provide site with informations for optimizing low latency/high latency storage deployment

Cloud on HLT farm: reached 15K concurrent simulation jobs

• Switch between trigger and simulation operational
• In Run2, expects 30% of HLT for simulation
  • Driven by trigger activities

Cloud computing: on going R&D, goal is to be able to use academic clouds and make an opportunistic use of public clouds

HPC centers: lots of opportunity for opportunistic use leadership class HPC centers in several countries

• Largest HPC centers have CPU resources comparable to ATLAS resources worldwide...
• Test activities started in US, China and Germany
  • currently done with a ARC CE: one per HPC center
• Concentrate on simulation and event generation: HPC centers difficult to use for I/O intensive jobs

The most constraining service for ATLAS is the storage: must remain in control of ATLAS

• With evolution of the network, reduce the number of data centers serving the computing resources?

ATLAS planning a data challenge in 2014

Operations

• Sites requested to provide a WebDav endpoint to rename SURL in preparation of Rucio deployment
  • Want to complete the migration by the end of this year
  • Progression at each site tracked with a GGUS ticket
  • Twiki pages in Atlas and WLCG Twiki
  • Switch to Rucio planned early 2014
• Access protocols for DPM sites: recommendation is Xrootd direct I/O for analysis, Xroot copy to scratch (xrdcp) for production
• CVMFS: all sites requested to upgrade to 2.1
  • A requirement to be able to upgrade CERN servers
• CVMFS monitoring: ATLAS would like to a see a tool developed, VO agnostic, to check CVMFS repository validity and put a WN offline automatically in case of problem
  • I. Collier: a Nagios check is already provided by developers. Is it not enough? May be only a matter of deployment
  • Discussed/followed-up by WLCG Ops Coord
• AthenaMP is ready for production but waiting for a common agreement in WLCG about how to dynamically allocate multiple cores
  • Need also to make the accounting properly counting multi-core jobs: John Gordon says it should be feasible but requires EMI-3 and some work...
• FAX integration progressing: lots of testing, including stress testing
  • Mainly for input failover initially but may be used for job brokering with relaxed constraints on data locality in the future
  • May evaluate http-based federations in the future

ALICE

Operations

• SLC6 at CERN: lower efficiency, higher failure rate, being investigated
• CVMFS: very good progress, quicker than expected
  • A few new failure modes but no impact on operations
• Sites required to upgrade VOBOX to WLCG VOBOX
• SHA-2: ALICE and used core services ready
• glExec: not currently used by ALICE but adaptation is planned, sites encourages to deploy it accordingly to WLCG requirements
• Production ok: no shortage of resources

Started to think at future challenges for ALICE computing in the light of Run3: some changes to be introduced during Run2

• With Run3, will need a 20x in computing resources
  • Cloud may be the underlying, appealing technology...
  • ... but the cloud is not an end-to-end system: need to rebuild a distributed infrastructure (grid?) on top of it
  • Storage is an area where cloud has no out-of-the-box solution for our needs...
  • ALICE File Catalog is one piece that will not scale for Run3
• ALICE should move to more delegation to regions for implementing reliable data and computing services: current central management of sites cannot scale
  • Probably better done by other experiments today...
• Various SW improvements may help but still a high risk of resource shortage in the future
  • Flagship class HPC center are attractive as they can provide very large resource for opportunistic use: CMS approach (parrot) tested successfully by ALICE at ORNL
  • Looking at PanDA as a way to be able to use more resource types: interfacing PanDA machinery with ALiEN CE should not be a major issue
• Need to foster collaborations with other LHC experiments: several synergies possible
  • ALICE wants to reduce solutions ALICE specific

2020 Outlook

HEP Vision and Long-term Planning - I. Bird

Computing model update

• Requested by LHCC, to be delivered at the next meeting in December
• Describe changes wrt to original models
• Optimize use of resources, reduce operational/support costs
  • Enable use of opportunistic resources: continue to move grid complexity to application layer where it better fits
• Emerging technologies: clouds, data federations...
• Challenge of SW performance with new architectures
  • HEP SW reengineering needed: focus on commonalities (GEANT, ROOT...)
  • Still working on the idea of a SW collaboration that could provide and credit additional efforts
• Focus on resources/capabilities rather than tier roles
  • Hierarchical structure is no longer there anymore
• Evolutions of requirements vs. expect price evolution: could work with flat budget and expected price evolution...
  • But in fact probably slightly decreasing budgets...

Significant increase of data rate expected in Run3 (ALICE & LHCb) and Run 4 (ATLAS & CMS)

• ~10x factor
• Cannot expect increased budgets: no alternative to working on improving performances (1/2 to 1 order of magnitude)
• Must revisit our distributed model
  • Network will continue to offer higher bandwith (2023: 10Tb networks expected): remote access to data will become cheaper than moving them (local disks needed), no reason to have data locally to physicists
  • Distribution has a high operational cost: would be more efficient to have 10 large centers than 150 smaller...
  • Explore the CDN (Content Delivery Network) model used for video on demand and web contents: ATLAS event service is a first attempt to implement this model
  • HLT farms will become much bigger: use them also for offline activities (already started)
  • Will require a change in funding models
• Proposal to hold a series of workshop for long-term planning (10 years) and rethink our computing infrastructure

Long term strategy

• Build on our current expertise: large scale data management and distributed computing
• Foster relationships with other communities
• Data preservation
• New analysis models based on querying datasets rather than using an event loop?

Discussion

• Moving to the proposed model is not necessarily a matter of huge developments: we are already half way with remote data access and simplified job execution services

e-Infrastructure for the 21st Century - I. Bird

External funding that used to exist in EC and US largely stopped

• Future opportunities may exist but we have to demonstrate that we do can benefit other communities and we must engage with industry
  • No chance for HEP-specific proposals
  • Already some records of collaboration with other communities through the grid project and with industry (OpenLab, Helix Nebula)

Changing times

• New sciences treat computing infrastructure as OPEX rather than CAPEX, leading to different infrastructure (cloud rather than grids)
• Current DCIs not sustainable as they gave the perception their use is free

Key ideas for future e-Infrastructure

• Bring together public funded infrastructures and commercial partners in an hybrid model: Research Hub Accelerators
• Future e-Infrastructure must be driven by science communities
  • Something we failed to really do in EGEE/EGI

EIROforum published 3 papers describing these vision for the future

• Sustainable infrastructure: large experiments/facilities currently in construction must be convinced that these infrastructure will continue to exist during the whole lifetime of their projects
• Inclusive and flexible infrastructure: need to support all science activites, including long tail of science and interact with other regions
  • No a "one-size-fits-all" solution like grid
• Service consolidation: not user or infrastructure fragmentation, avoid duplication of services
  • Built upon strong networks and identity federations
  • Small number of large facilities providing data services and cloud services
  • SW services and tools to provide value-added abilities to research communities
  • Data continuum: open access to data

ReAcH: Research Accelerator Hubs

• A hybrid model made of public and private service suppliers
• A prototype proposed to be built in 2014
  • CERN will contribute this prototype with resources installed in Budapest: multi-tenant computing services accessible through single sign-on, long term archiving, dropbox-like service
  • Users expected to pay for this service after the first initial use: details still to be discussed, not necessarily paid by the end user (may be by communities or even at the country-level)
  • EMBL-EBI has a similar project, centered on life sciences
• Open questions: how HPC centers and EGI fit in this model
• Existing grid sites that will not become a ReArC center encourage to contribute using volunteer computing model
  • Leverage on work done by project like EDGI and DIGISCO, International Desktop Grid Federation

Discussion

• Several disagreeing about the idea that grid resources are free: in fact paid by organizations to support particular communities. Not so different than a "pay-per-use" paid at a governement level...
• Lothar Bauerdick (OSG): OSG has been pretty successful so far in making the infrastructure useful for other communities, including non-physics sciences. No sign that this model cannot be sold anymore in the US
  • I. Bird: US has the advantage of being a single country, in Europe we have the problem of different countries with different views that adds difficulties
• C. Grandi: need to take into account existing sites. What they become in this new vision?

e-Infrastructure User Forum - J. Shiers

See slides for details.

Proposal emerged in EIROforum to get more user-driven e-Infrastructures

• Next meeting to discuss it further next week at CERN
• How to ensure representation of small communities as well as the big ones represented in EIROforum?
• Feedback to the WLCG community about the progress will be welcome at a future GDB

EGI Evolution - T. Ferrari

See slides for details

Wrap-Up - M. Jouvin, I. Bird, M. Girone

Thanks to all participants for coming

• Several reported they'd prefer colocation with CHEP: may take it into account for future workshops
  • Maria: co-location also has drawbacks, not the same attendance, wanted to give more chance to the participations of people not coming to CHEP

Thanks to the local organizers: the meeting was very smooth

The workshop showed that the work in progress for Run 2 is well inline with longer-term vision

• Remote access to data, demonstrated in data federations, is the foundation for fewer/larger data stores
• Cloud services seen as the future by all experiments and already well integrated in experiment frameworks
  • Need to make the WG on cloud more active: in particular need to make progress on the ability to build multi-tenant clouds with target shares without static partitionning. Will probably not come from commercial clouds where the target share is defined by the credit card...

Need more discussions on both the work in progress and the long-term vision

• Need a yearly workshop like this one
• Need more focused meetings/discussions during GDB or pre-GDB
• For the long-term vision, should bring input from non-European infrastructures, in particular OSG

Thanks to Maria Girone who was the main organizer of this meeting and is moving to new responsibilities

• Thanks for her involvement and decidation to WLCG service coordination
• Good luck for her new responsibility (CMS Computing Coordinator)

Welcome and good luck to Simone Campana who took over from Maria.