Design your e-infrastructure. https://indico. egi Design your e-infrastructure! https://indico.egi.eu/indico/event/2895/ Use case: Birdhouse Break out group coordinator: Jan Bot and Roberta Piscitelli SURF SARA – EGI.eu

Group members Jan Bot (SURF SARA) Genevieve Romier (CNRS) Romain David (IMBE) Teresa-Gomez Diaz (CNRS) Catalin Couderoche (STFC Rutherford Appleton Laboratory) Carsten Ehbrecht (DKRZ) Roberta Piscitelli (EGI.eu)

First break-out Background and Users

Who will be the user? Can the users be characterised? How many are they? Two kinds of groups: Data providers Users Not really aware of the system Users who need to implement the service itself People familiar with data processing The amount depends on the use case provided, ranging from 10-20 in case of data providers to 50-100

What will be the value of the infrastructure for them What will be the value of the infrastructure for them? What will the system exactly deliver to them? 1) Value of the infrastructure for users For users who use quality services it would be a convenience For ordinary users data access is a problem, so the value is in accessing to data to process it. In case of WPS they provide processes, which are community specific it would be the combination of having data accessible and operate on it. The benefit is providing this type of integration 2) The system will deliver mainly Connecting processing services to data In other use cases it will provide data to a broader community

How should they use the system? Normal users will use a portal The WPS provides the services The applications offered to the advanced users are exactly the same The value of EGI would be to implement the entire system EGI could help with dissemination

There is already a system available as prototype What's the timeline for development, testing and large-scale operation? (Consecutive releases can/should be considered.) There is already a system available as prototype For metadata checks it should be ready by the end of the year For Copernicus it should start in the summer and it should last 3 years for development The timeline is strongly dependent on the project, according to the features requested (from hours to years)

Design and implementation plan Second break-out Design and implementation plan

What should the first version include What should the first version include? - The most basic product prototype imaginable already bringing value to the users (the so-called Minimal Viable Product - MVP) The first version would include portal and WPS system, with access limited to the portal and not directly to the WPS

Which components/services already exist in this architecture? WPS itself Access to storage Portal Terminal client to access to interact directly to the WPS Missing: Proxy for authentication system, which talks to the different AAI systems and knows the WPS protocol The scheduling system to access to computing resources needs to be integrated

Which components/services are under development (and by who)? Proxy for authentication system, which talks to the different AAI systems and knows the WPS protocol Implemented by DKRZ and KNMI The scheduling system to access to computing resources needs to be integrated Implemented by DKRZ, BADC for Copernicus use case (same service implemented by different entities, and will use different plug-ins)

Proxy to handle different AAI Which components/services should be still brought into the system? Can EGI/EUDAT partners do it? Proxy to handle different AAI EGI/EUDAT provide this service Docker system to connect to different schedulers EGI/EUDAT do provide dockers, however they do not enable users to use dockers to implement this functionality Schedulers could also be brought by EGI, but there are some technical issues to do this

IdP Proxy can handle different AAI systems Are there gaps in the EGI/EUDAT service catalogues that should be filled to realise the use case? Which service provider could fill the gap? DIRAC could be a good abstraction layer to submit jobs and schedule them in different sites IdP Proxy can handle different AAI systems EGI would redirect to the right NGI to provide resources to your community To validate the docker solution, it would be possible to request EGI some resources to test this solution, this would provide you with the required knowledge to run it.

Next steps DIRAC for job and Docker container scheduling; Organise a DIRAC training webinar, covering relevant features EGI AAI proxy for user access Connect use case provider with EGI AAI proxy team to arrange application of this service for the use case