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

2. 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)

3. First break-out
Background and Users

4. 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 in case of data providers to

5. 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

6. 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

7. 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)

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

9. 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

10. 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

11. 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)

12. 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

13. 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.

14. 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