EGI-InSPIRE RI EGI-InSPIRE EGI-InSPIRE RI Regional tools use cases overview Peter Solagna – EGI.eu On behalf of the Regionalization task force 6/26/2016 1

EGI-InSPIRE RI Summary General overview GOCDB SAM/Nagios Operations Portal Helpdesk/GGUS Accounting 6/26/2016 2

EGI-InSPIRE RI Regionalization Task Force Define use cases for the regional tools, analyze the dependencies between the tools. Input for possible requirements for the developers. Wiki: Three meeting in the past 4 months: 3 March, 27 April, 16 June Participants: Many developers but few NGIs Torsten Antoni, KIT Goncalo Borges, LIP Wilhelm Buehler, KIT John Casson, STFC Daniele Cesini, INFN Tiziana Ferrari, EGI.eu John Gordon, STFC Guenter Grein, KIT Cyril Lorphelin, CNRS Giuseppe Misurelli, INFN David Meredith, STFC

EGI-InSPIRE RI General considerations Advantages of a distributed scenario: Customization and extension of the tools Local services may reduce the impact of central tools downtime Central tools can be a backup for regional tools outage General requirements for regional tools: Good documentation for both installation, customization and extension of the features. Simplified installation and configuration

EGI-InSPIRE RI Dependencies between regional tools

EGI-InSPIRE RI GOCDB regionalization scenarios Three GOCDB development proposed: a)Scoping the data into central GOCDB GUI enhancement, tagging logic NGIs can selectively publish their site/services without the overhead of deploying a regional instance b)Regional stand-alone GOCDB NGIs can fully customize their data, but no data synchronization with the central instance c)Regional publishing GOCDB EGI scoped data reside in both central and regional GOCDBs Requires developments in scenario a) Long term development GOCDB has no dependencies with other regional tools

EGI-InSPIRE RI GOCDB use cases Storing non EGI data Register both regional sites and local services in EGI sites Central and regional GOCDB should be able to differentiate between EGI and non-EGI data All GOCDB entities need to be tagged ‘EGI’, ‘Local’ or some other scope Available in all the development scenarios It could be useful to have three views: EGI + local data Only EGI data Only local data (e.g. to set-up a specific Nagios) Extension of the GOCDB schema for some NGI specific purposes Only possible in b) and c) scenarios Extension should remain local: the central data will not be affected Documentation: How to properly extend the database schema, adding or altering tables. How to create SQL queries to retrieve the new data Tutorials describing how to implement in the GUI the forms to manage the new data (input forms, output pages)

EGI-InSPIRE RI SAM/Nagios use cases (1) Monitor sites and services not in the central GOCDB Monitor with the current set of probes services/sites not part of the EGI infrastructure: test sites, sites funded separately Dependencies: ATP needs customized information sources GOCDB, Operations Portal, VO feeds, BDII A regional instance of the GOCDB is mandatory (in general information sources can be excluded, but not the GOCDB) Multi VOs Nagios Currently it is not easy to run probes with different VOs Enhance probes with more specific VO checks Differentiate VO checks among different hosts/services in a multi-VOs Nagios

EGI-InSPIRE RI SAM/Nagios use cases (2) Run custom probes Add new probes to the default set. (E.g. VO-specific probes, new services or different thresholds for existing probes) Does the current JRA1 policy for new probes envisage the possibility to add local probes? Custom availability reports based on the extended set of probes Dependencies: POEM (MDDB successor) still under development Regional instance of POEM was planned, but there is not yet a timeline for the development Understand how this tool will provide the possibility to add new metrics related to customized probes New profile for availability calculation algorithms that include the new metrics GOCDB New services will need new service types Using the central GOCDB (even with custom views) it may be impossible to add specific service type for every NGI A catch-all service type (e.g. “CUSTOM LOCAL SERVICE”) may be the solution

EGI-InSPIRE RI Operations Portal use cases (1) On demand regional alarm to be added to the Operations Portal Define new critical alarm as required by an NGI on ROD scope only Switch on and off new alarms on demand Not for the default set of alarms Manage alarms and tickets for non-EGI services and sites in the dashboard ROD may need to operate on both local and EGI sites Tickets escalation to COD must be performed only for EGI sites Central Operations Portal can already be configured to point to a custom GOCDB. A possible feature for the regional instance would be to support multiple GOCDBs

EGI-InSPIRE RI Operations Portal use cases (2) Different helpdesk for regional Currently the dashboard opens tickets in GGUS, the regional helpdesk pulls the tickets from the GGUS web service Regional dashboard should directly open tickets in the regional helpdesk Use different helpdesk for different sites Currently under development support for xGUS and RT Dependencies with other regional tools Nagios GOCDB Helpdesk

EGI-InSPIRE RI Regional helpdesk Regional helpdesk scenarios xGUS is a custom service hosted centrally. No overhead for Operations Centers that need to deploy a regional custom helpdesk Currently configured by hand, an improvement would be to pull the sites from the regional GOCDB RT ticketing system GGUS can interface with RT for ticket synchronization RT integration task force Other custom helpdesk

EGI-InSPIRE RI Accounting No big developments needed for the regional instance of the Accounting portal It is basically a global portal that is querying a regional accounting repository Dependencies on the regional GOCDB to build the list of accounted sites Accounting repositories Regional accounting repositories that publish summery records on the central instance Direct publish to the central repository will be still possible Custom NGI accounting system Regional accounting use case Keep local accounting data for certain VOs The regional repository should implement the logic to choose which data should be forwarded and which data should remain local

EGI-InSPIRE RI Conclusions Outcome from the task force: Use cases Most critical tools: GOCDB, Ops.Portal, SAM Dependencies and interactions between regional tools Next steps: Translate use cases into requirements for features (where needed) Identify timeline/deadline for the implementation of the new features in central/regional tools