 So, if you want to have any questions, please use the raise hand function, if you want to speak. You can also provide information in the Zoom chat, but for the questions, we also use a Slido. Within Slido you can go to the session which is listed below. In the Slido we have the Q&A, but also a session for having a few questions for information. This is the agenda of the session. First we have an introduction about the activities we have done on the technical architecture and we have a few examples of architecture descriptions for the different kinds of services and we have also a use case about adopting the architecture guidelines. After the first and the second block we have a short Q&A. If you have questions after those sessions, please use the raise hand functionality for getting the question and getting unmuted so that you can ask the question. At the end we have a larger block of Q&A, which we use a Slido, so if you have questions which are not just answered within the session, please put in the questions within the Slido. Then we can address those questions. If you go to Slido and you see questions which you like, please do the thumbs up for the questions so that you can also probably ask questions while answering. Within the Q&A final session we start up with a few questions. Then we go to switch to Diego. Can the screen share be switched? I will stop sharing. Then I will introduce Diego. Diego is a technical solution team lead at EGI Advasion, which is in his team, where he is technology provider and research innovation projects for technology and innovation for the existing EGI services. Diego is also the coach of the EOSCAP Activity Management Board. Thank you very much, Marc, for the introduction. Can you probably see my slide? Yep. OK, fine. OK, let's start then. In this presentation I will introduce the EOSCAP proposal for the EOS technical architecture. This made the framework to foster integration and interoperability within the EOSCAP environment. I will stop then presenting this proposal. Then I will give you some information about the first result of these activities. And I will close my presentation with some information about the next steps. OK, as you know, within EOSCAP, the concept of service-conservatability has been considered one of the most relevant. Well, as a composability, we mean the possibility to put together, to allow to work together two or more services to provide added value. Then to allow the service together to do something more. Then, for this reason, in EOSCAP, we developed a service-aided integration and the composability framework that is based on interoperability guidelines. We'd aim to one side facilitate the exploitation of EOSCAP services, and from the other side to foster the service integration, the composability, to also then facilitate the combined usage of EOSCAP services. As interoperability guidelines, we intend to promote the adoption of standards and well-known APIs to support the end-to-end composability of the services. This interoperability guidelines should be able to lower the barrier to allow to access the service, to use the services. And the idea is that we don't have to reinvent the wheel, but these guidelines should be based on existing community practices with no standards in the face and so on. So the work that we are doing is mainly to collect information about the different technical areas about the most relevant standards, the API that are adopted, and try to put them together to define these interoperability guidelines. The idea is not to make these guidelines mandatory, but each provider should be able to decide to adopt them or not. Our wish is that the advantage to adopt the interoperability guidelines will be so big that the providers will adopt them for their proper interest. What are the benefits of having this framework? First of all, having this framework, having a wide set of interoperability guidelines would allow the scientists to compose services in a easier way. In addition, the scientists can rely on infrastructure and use compliant services for implementing basic features. For example, a scientist that doesn't need to worry about AI or monitoring or accounting or the orchestration on top of a cloud environment since the scientists can reuse the services delivered by the infrastructure, they can focus their work on the scientific aspect. In addition, the interoperability guidelines can help federated and common services to interoperate and to work together. For example, AI systems from different communities or accounting services from different initiatives can be merged and working together if they are compliant with these guidelines. Starting from this, we decided to develop ESC-referenced technical architecture as the framework, the containers for all these technical interoperability guidelines. A reference architecture is a template solution for that architecture and we decided to work at an infrastructure level. So the idea is that we decided to split the ESC services in three main categories, the federation services that would be made in the services to enable the ESC operation or basic features that are needed to properly support ESC, we can call them ESC services using the most recent terminology. The common services that provide genetic functionality that can be applied to multiple domains making imaging a cloud of cash threat or for example, or data repository or data management services that can be reused by scientists from different scientific initiatives for example, these are common services and the thematic services that address a specific research domain. So we split the services in these three categories, under these three categories we define the functional categories that where we have identified the functionalities that should be offered by the services and behind this we define the main element of this architecture that is the bidding block. The bidding block represents a basic element of the infrastructure and is defined by a set of parameters like the scopes, the features that are offered, the standard that are supported by these bidding blocks, the API that are offered, we also included a list of example services implementing this bidding block. So if we consider the different features that are needed to implement a scientific service, bidding blocks can be under the federation and access naming category can be the AI infrastructure or a monitoring service and the common category can be a cloud cash threat or can be a data repository and the thematic category can be a specific component that is resolving some problem that is specific to a scientific discipline. After we have defined the framework, the activities consisted on identifying and defining this EOSC architecture building block for all the service types and then we have agreed to mapping the feature of each block to a technical specification for the building block that includes an high level architecture that highlight the main feature of the bidding block, the interface and so on and interoperability guidelines. So what is needed for a service provider to use this building block from one side since we know in the specification we made available the interfaces to interact with this building block in addition for a provider that is willing to provide a service that implement this building blocks what are the interface that have to develop. So it's a guide for both the providers that are willing to exploit the building blocks that both and the providers that are willing to implement a bidding block. Obviously the EOSC is a very wide environment so it's a very complex identify all the bidding blocks and define the specification for them. We decided to use an iterative approach to both identify the building blocks and define the technical specification and this work has been driven by the use cases. So we selected the most relevant building blocks that should be specified from the use cases. We are working on defining a technical specification, some specification already available and the idea is to get feedback from the wider EOSC environment to improve them and then creating a new version accordingly. Since this specification should be considered like some live document that needs to be continuously enhanced. Obviously our intention is also to involve people not directly involved in the project but with expertise in the area of a certain building blocks to work on this. This slide is to better show you what is the concept of building blocks. When we talk about building blocks we are not talking about a specific service instance but we are talking about a family of services that are compliant, that are conformed with the specification of the building blocks. Then a service can be part of the building block if it's followed the technical specification then implement the high-level architecture and the interoperability guidelines that are compliant with the specification. Example of services that are part of the same building block are for example the AI services compliant with the Arc of Blueprint architecture that it would be all together within the AI building blocks. Also monitoring all accounts system, the table to exchange share information between them and working together. Previously I showed you how we have defined the framework of the technical architecture to identify the different building blocks according to the service type and then define the related technical specification. This slide shows the functional view of the use of technical architecture where we have defined, we have the same three main categories of services, the thematic services on the top, the common services in the middle and the federation services on the left. All these services work together and the user can exploit these services of directly accessing thematic or common services or to the use portal or any other portal marketplace. The most relevant information from this slide is you can see it in the common service area that has been detailed where you can see different elements, the workflow management, the cloud infrastructure service, cloud orchestrator, data discovery management, all of them are building blocks and for all of them we have defined for some of them the interoperability guidelines that would allow to specify the APIs and the standards interfaces to interact with these building blocks. What does this mean? This means that for thematic services it's simpler using one or more of these building blocks since the thematic services can rely on well-known API standards interfaces. This is a show with the powerful arrows in the slide. The same is about the interaction between building blocks since also building blocks can work together to provide added value for example to thematic services. This is a show with the red arrow in the picture and you can see for example the workflow management of building blocks is interacting with the cloud infrastructure service building blocks to the API standard interface. The main idea is to have clear interfaces and I would say interfaces that are promoted within the user environment to simplify the integration work between different services with the final aim to have composite services with less effort. This is the main point. Okay, that's all for the introduction to the framework that we have developed. Now I'd like to give you some information about the first result focusing on the technical specification for federation services that we have we have developed. This specification, the federation service can be seen as what we are currently calling use core services that can be seen as candidate services to be included within the use core services and for each of these services we defined as I described before a high level architecture, the interoperability guidelines and related integration options then it means how a service provider can be integrated with these services offered by YOSC. We have defined a specification for AI, for the monitoring, for the AluDesk and for the accounting. Very important for each of these services we have defined within a distributed architecture since YOSC I would say is intrinsically distributed but within this distributed architecture we have identified if it's needed having some functional central services offered by YOSC and how a service provider can integrate with these functional central services to some interoperability guidelines. Specification for monitoring, accounting and helpdesk are currently open for public consultation. The deadline to get feedback is the 31st May, the end of May. The link to the survey that we have created is in the slide. I would invite everybody to have a look at this specification and provide the input so we can create a second version of this specification in the next month that takes into account the input from a wider set of people. Okay, starting from this I'd like to show you an example then specifically about the helpdesk or what does mean having this kind of specification. This specification we have defined would be the YOSC helpdesk. The idea is that the YOSC helpdesk would provide the first level of support for all the YOSC services and then in particular for all the services of country onboarded in the YOSC portal. A second level of support for the YOSC services, like the YOSC portal marketplace, the AI monitoring, a three integration options for all the other YOSC services. If you see the diagram on the right of the slide, the big box with the dashed line is the YOSC central helpdesk that would allow from the YOSC portal, would allow the user from the YOSC portal to submit incidental service request. Then we have a first level support team in the helpdesk that will take care of this of this ticket or this request from the users for some of them in an automatic way. Let me explain how. Then the provider can decide to integrate with this YOSC helpdesk in three different ways. For example, if a provider doesn't have its own helpdesk, it's free, you can decide, it's up to the provider to use the YOSC central service on its own helpdesk. In this case, a dedicated staff of the unit for this service provider will be created and the YOSC will provide the tool to allow the service provider to manage the request from the users, but obviously the provider will have to provide the people to deal with this request. The second option would be when there is a service provider with its own helpdesk and the service provider wants to continue to use its own helpdesk, the user can directly access the service app to the provider as usual, but in addition, since we can receive centrally some requests from services of this provider to the YOSC helpdesk, this request will be automatically, so without any user interaction forwarded to the helpdesk of the service provider to a certain interface, to a certain interface that is specified in the YOSC technical specification. So if the provider implements this interface, that is this arrow, the ticket will be automatically forwarded to the provider. This is how to say it's the nicer way to integrate a provider, but in this case the provider includes in a certain effort and a certain cost to integrate with the YOSC, since they have to implement this integration. It's a low cost, but in this case it exists. So we also included a third integration option that would allow a provider to integrate its own helpdesk with the YOSC helpdesk, without effort, I would say, since the YOSC helpdesk will forward the request for the service of this service provider to an email. Then when the ticket is created within the helpdesk of the providers, the provider will continue to manage this ticket as usual according to its internal procedure. So this is the structure. As you can see, we have tried to create something less invasive as possible, and then I would allow to satisfy the needs of different kinds of providers, more mature providers with their own services, they want to continue to use less mature providers that need support from YOSC to have some operational services up and running. These are the three integration options that I have mentioned. And the hour between the YOSC central helpdesk and the provider helpdesk have been the disinterface, have been defined and the interoperability guidelines. Okay, that's all from the specification for the cost services. Very quickly, I'd like to say that this work is user-driven. I mean, we are trying to define technical specification according to the real needs of the user, and we use a very wide set of use cases to drive this work. Use cases are coming from all past projects like YOSC pilot, use cases coming from YOSC hub, like the thematic services and company center, but also use cases that we have identified to the YOSC portal marketplace. And this slide to show you how the different requirements that we have collected from the user communities are driving the development of the guidelines that we have defined. Okay, now to conclude, I'd like to give you some more information about the status and the next steps. We have already released 13 technical specifications. These are available in a deliverable data that's been produced by YOSC hub. The link is in the chat, but we are also creating a website where the user can easily access and navigate all these specifications. This will be available very soon. We launched in autumn 29 a public consultation on the overall approach that I present today. We got answers from Eric's YOSC class regional approach, the other infrastructure and so on. And we got a general positive feedback on the approach. I think the most relevant comments that we got is trying to make this effort as much as possible use case driven and we fully agree on this. There is another public consultation that is ongoing, as already mentioned before, on help desk monitoring and accounting technical specification with the deadline the 31st of May. And I would invite you again to provide your feedback so we can improve this specification. And finally, the YOSC hub technical workshop of this year would be run in a reduced format, considering the current out-of-the-back crisis in an online session tomorrow during the YOSC hub week. So I invite everybody to also join this session to get more specific information about the specification we are developing. Yeah, there are some elements and that's also my side. Okay. Diego, thank you for this presentation. I'm looking at the participant list at the moment. I do not see any hands raised, but then I think we can also switch to the next. I see one hand raised. There's one question in the chat as well. Yeah, can you unmute? Juri? Yeah, okay, so I have a question. Yes, this is very interesting development. It's a pity that I missed this at the time it was announced consultation. I don't know why it was not reached to quite the community like YOSC or a academic or LTA community. But what I see, it's the right way. But my question, the session is called YOSC hub contribution to YOSC architecture. Do you see some problems? Because I see this would be a real contribution to YOSC architecture, but this not happens at the level of YOSC architecture working group with my understanding. Do I understand correctly? Let me, for about the first part of the question about the public consultation, we tried to make this, I would say, as wide as possible. We also published a post in the YOSC platform to try to reach how many people are possible. So I'm sorry that it wasn't possible. But in any case, having feedback also, you want to provide me a feedback that would be fine. It will be surely, we will try to surely to take into account since this is, as I said, something that need to be done with an active approach. Currently, there is open public consultation on the help desk accounting and monitoring technical specifications. So I would invite you to have a look and provide your feedback. You can also try to put some generic statement in this about the general approach. We can try as much as possible to improve our approach, taking into account the comments from everybody. Thanks for this. For the second question, YOSC is part of the YOSC architecture working group. Mark is the YOSC staff member of the YOSC architecture working group. And this work has been presented by Mark more than one time, I believe, to the YOSC architecture working group. I also presented this work during the YOSC symposium in a session that was chaired by Jean-François Brahmatic. And I think there is also a general interest also the working group on these activities that should be also followed up in the next project, YOSC project. But currently the working group is mainly focusing on few topics. So they didn't have the time to to further contribute on this. This was my understanding. Maybe you can add something on this. Okay, Diego, can I ask a follow-on question? What is the foundation or background for this? For me, it resembles like you are moving into the direction of like DevOps, automatic service deployment, design templates. Am I correct or not? I think this strictly depends by the area that we are, the technical area that we take in consideration. Then from some area, all this aspect would be very nice. Diego, I want to intervene a little bit because we are running out of time for YOSC missions. But we can pick up this question also at the end of the session in the Q&A larger section. It was also mentioned that there are some questions already in Slido and also want to pick up those questions at the end of this session. Therefore, I want to go to Adrian for presenting the accounting. Adrian works at the FGSE, part of the UK Research and Innovation. He has slept on the April users' accounting system for over four years, for which he has been contributing to a number of EU projects and the latest one is EOSCup. Adrian, I'll let you have muted, so thank you, you can start. Yeah, the slides showing okay. Yes. Okay, cool. There we go. Yes, so after the introduction, I'll cover the main features of the YOSC accounting. Look at the highlighted architecture and then look at the different ways you can integrate with that architecture and then finish with the interoperative guidelines. This is all covered in more detail in the technical document that's been mentioned by Diego. The YOSC accounting service collects various types of usage information for compute and storage and cloud VM usage and processes those and displays them via a portal. The value proposition for it is basically accounting is the central part of a federated infrastructure because you need to know that the money you're spending on these resources is being used and that the communities that have asked to use resources are getting the use of those resources. The main features for the user, it provides aggregated views of their usage, whichever resource center that usage occurred at and also provides you views that allow their usage to be checked against their allocation. The resource providers, it gives a provider-centric view of the resources used. They can see who's using their resources and also allows comparisons to be made between resource providers in different groupings depending on the topology of the federation, so different communities or different regions and so on. The high level architecture is the resource centers implement some sort of collector that gathers metrics and then they're formatted into a standardized format and then they're sent via messaging service to a repository which can then process those to give aggregations across all the different resource centers. These are then sent to the accounting portal and then the portal retrieves the topology information and community affiliations from other services to give you the variety of views. So in terms of integration, resource centers can either directly publish to the central accounting repository, that's the top path or they can have their own intermediate repository, a regional repository, or thematic even. And then another option as well is they have their own completely separate accounting system but to provide some aggregated views across all the EOSC infrastructure they can then also publish accounting records to the EOSC accounting repository. So in terms of interoperability we use a selection of standardized usage records and then the metrics and units need to be in a compliant format and have the correct semantics. And in some places if URL pointers are used these should ideally be public to enable linking from the portal. Sometimes these are used for linking to metadata about the sort of VM images that are used. So this could link to your repository of VM images or something like that. And I mentioned publishing via a messaging service and alternatively in some situations we have agreed on an HTTP API that we can pull the data from but this isn't widely used at the moment. And then the property information should follow, that's the version that's used by Gocti B and yeah the simplest way that resource center can integrate is just to register their services within Gocti B as that will mean it's the same correct format. But there are other ways to publish this information for topology. And lastly yes the AI should express the group memberships in a standard way so that you can get the correct views on your data as well. Yeah and that's me done. Okay Adrian, thank you. Then we go to Pavel presenting further details on the help desk. Pavel is working at the Car House Institute of Technology in Germany. He's leading ESCAP work packages with focus on the integration and maintenance of the Federation collaboration services. Can we switch to Pavel as presenter? Sarah, can we switch to Pavel? Yes. Hi. Hi Pavel. Are you sharing yours to your slide? No, I can't share my screen. Okay, can you share? There is the button on the screen on the Zoom. Otherwise I can put up your slide. Most disabled participants screen sharing. When I try to push this button, it's okay. I will share your slide. Okay, thank you. Okay, thank you. Okay, so then I start. So I will tell you a bit more details about the help desk and this is a short outline. I will start with introduction. So the help desk is the entry point for ESC users to submit incident report on issue a problem request information for the available ESC services. On the other hand, the help desk in the ESC ecosystem is a backbone service of the incident and request management process which facilitates, for example, communication between customers, users and service providers, also service recovery within a great time. I think it's a bit too far what I see on the screen. I'm still by introduction. Okay, is this not an automated maybe? Got to transfer one slide to the other? I think that that's why, because I was not. Okay, so yes, so and also it facilitates service recovery within a great time in SLA and allows to manage service requests submitted by the users in consistent manner. So next slide, please. So first, I also would like to explain main features of the help desk, which we also divide into target groups, ESC users and ESC providers. Next. So the ESC users basically interested in creation of tickets for any ESC services for any of your service and hub and ESC portfolios to have open access to all tickets and to have opportunity to submit ticket without login and get notifications also have integrated access with the AI system. Next. And ESC providers, on the other hand, they interested to get scalable and interoperable architecture for direct usage, so to say help desk as a service and fast integration with external help desk systems if they're available. Also efficient ticket management is important and role and support unit management. Next. So actually Diego already described shortly the main integration options we developed for service providers. So this is direct usage when the service provider gets support unit or group of support units and get full management rights for them. Another option is a ticket redirection when the help desk just used as a contact point and redirects tickets to the provider's mailing list or ticket system. So this is a less integrated solution. And the final is the full integration via the main API protocols. This is bidirectional synchronization of tickets in EOSC and providers help desk. So if the help, if the ticket created in the EOSC help desk, it's immediately visible in the provider's help desk and also the service provider could manage tickets in the help desk of the service provider and then it's also visible. All changes are visible in the EOSC help desk. Next. Yeah, so this picture already shown by Diego. I just added here at the top EOSC portal and marketplace as a web interfaces for users to submit the ticket. And I don't want them to describe it into detail. So just if you go to next. So there's the three options, three different integration options provided for this architecture. And if you go to the next slide here is actually the current implementation in the EOSC hub. So here we'd like to say a bit more detail. So this is a multi-level structure of the support units. So we start with the zero level on top, which basically self support for the users based on the material provided in their portal, other automated procedures. And if it doesn't help, then the user actually addresses the request to the first level support. First level support using the known error database and manage the tickets and distributed to the second level or third level. So at the second level, there are multiple support units. On the left side, you see a container of support units actually for the central EOSC operations and EOSC EOSC units like service onboarding central activities of the EOSC. On the right side, you see a container which contains service providers and some of them can be fully integrated like we have currently for EGI help desk and UDOT or use other options which I presented before. And at the third level, this is connected to the hub portfolio. It's a developer support for some requests which cannot be solved at the second level and need some more detailed consideration. Next. So this is about the standards and technologies. Currently, we have adopted GIGAS, which is a global grid user support and it's integrated part XGAS, which is a lightweight system for small NGIs. This software has been successfully used for many years by EGI and WLCG and there is a SOAP protocol which is used for integration with other help desks. On the right side of the slide, you see OTRS. This is basically the future of the EOSC help desk which we are slowly moving to. So this is open source software which we will use next in future and also actually use all the procedures we developed so far with new software. So it's not that we start from scratch but all the structure we currently developed, all the standards and interoperability procedures will be just transferred to the new software. And we use FITSM for the procedures and policies. So we have set of policies and procedures defined. I don't go into detail. It's about how you manage the ticket and how you open it, close it and so on. And the last slide, I will say a few words about the future plans which I already started. So we're moving to the new platform based on the OTRS which has modern user-friendly interface, multiple communication channels. It provides also much quicker integration with major core components like AI, JIRA, CMDB, other help desk systems. It also provides SLA management which is important to properly manage the tickets according to the FITSM and ITIL standards. And it provides also customizable workflow. So the plan for this migration, so currently we're collecting and prioritizing the requirements. So feel free to contact me if you have some requirements or questions also after this meeting. And as I mentioned, with preservation of the current best practices and established procedures. And we expect the first prototype by the end of the year and we start in the next year with assessment and validation of the new platform by stakeholders and then come to production. So this is so far for the future plans which may be not directly related to the specification but I think it's useful to also to let you know. So that's it, thank you. Pablo, thank you. I see a note in the chat, maybe you want to respond on this, that OTRS 7 and 8 is no longer open source. How does this relate to going this direction with the NEOs? Yes, so as I mentioned, so we use the premium support. So it's still, I mean, there are two versions. So this is a community version and version with premium support. So we used the last one with a set of add-ons to provide different functionality. Tim. Okay, thank you. And then you go to Kastas. Can we switch to Kastas? Kastas has been working with GeoNet since 2002 and he's working as a senior project manager on the infrastructure and he's also the head of the department for EAP in a project strategy and proposals of the directorate of European and international infrastructure projects. He has been involved with the infrastructure since 2003 and is currently the task leader of EOSCOP for monitoring accounting messaging and security tools. Kastas, can you see my screen? Yes, I can see your screen. All right, so I'm here to talk to you about us. Diego initially, let's say, presented the the corresponding specification for monitoring. We've been operating monitoring in collaboration with GeoNet search and IN2P3 CNRS for quite some years and we developed this specification on how we want to evolve and how we want to see that the monitor will happen in the EOSCOP level of operation. So I will go briefly through the main features of the monitoring service. What are the adopted technologies where we propose to be used? What is the high level architecture we've seen that it operates and how we want it to evolve? And also, what are the use cases and the durability options or integration options we would like to propose? Monitoring is the key mechanism so that you can have an inside of the current, let's say, level of the services you are offering. And when we talk about monitoring in this context, we don't talk about fabric monitoring. We mainly want to see what the end user sees. So we try to emulate what the user does and try to identify and correlate the problems that may appear. For example, let's say a user may not have access or enough quota that a service may be, a site may be up, but the database behind it is not. So that for the end user he will see a service 500 error. We want to do that so that we can quickly inform the owners of the service that there is a problem XYZ and what is the problem as much as we can understand from the outside, a black box testing. And we want to also monitor the conformance to the multiple SLAs that may be in place. So it doesn't really matter that if the service is up only, but if the service responds within the agreed time that the availability of the services above what the SLA requires and all this information that assists us in order to provide available and reliable services, i.e. good quality services that come from the SLAs. What are the main features of such a monitoring service? It's A, of course, monitoring service. Monitoring service from the user perspective, i.e. try to understand what the user would do if it's an FTP server, not just ping the FTP that the FTP is there, but try to upload a file, download a file, delete a file, do all the operations the user will do. Then we collect these results and do a reporting of the availability of the service as the user will see it. We do offer, of course, a visualization of the service status and how the service behaves throughout time. We do provide dashboard interface so that you can see and get the errors and you can understand what's going on and what is the quality of its service and if all the service dependence is behind it. One more feature what we've seen that it's been in high demand is real-time alerts. We don't want someone to have a dashboard open on the desktop and have someone monitoring that. We want to be able to send an alert to the individual service admin and notify them, hey, we've noticed this problem which caused by XYZ issue. Can you please fix that us up? In a scale or like EOS or in the scale of EOS Hub, it makes sense that we do need to have multiple entry points by, for example, multiple topologies, multiple profiles, multiple probes and ideas that we need to import to the system. We cannot say that this is a topology that is defined by only one source. You need to be able to combine multiple entry points. You need to be able to combine multiple different systems that may be producing topology, that may be producing data, monitoring data for this. You don't need to be able to be interoperable with data and try to understand what other systems do and try to import this into the system to provide a unified view. Of course, it needs to be highly available. To be so, it needs to have multiple instances of the same component running in parallel. It needs to be loosely coupled so if something fades, you can easily replace it with something with a new instance and try to scale out as needed. You probably need to support also different tenants so that, for example, infrastructure can have only, say, can have their own view and their own profiles for this, which can then be also integrated with, say, the global view, but they probably need to have their own unique way to monitor things. All the components we've used and all the components that they are defining in this spec are based on open-source software like Django, Python, and languages like Java or Golang. We do use the Avro schema as the mechanism to transfer the data, as the encapsulation schema. And for the computation of all this, we've been using the last couple of years Apache Flink, and it seems to be working quite nicely and it's quite flexible enough in order to be extended to do more things. Sorry, because I have this thing in front of me. The high level of architecture of the monitoring service starts with what we call the source of truth. The source of truth gives us the topology we need to monitor. We give us the profiles that we monitor, give us the factors that we need to take into account in order to be able to do our computation for availability or status. This is then passed on to the monitoring engines. The monitoring engines execute the probes, the metrics, and the profiles and produce results which are sent to the messaging service to be transferred to the computation engine. The computation engine uses the profiles from the source of truth and knows that the topology and what kind of computation you want to do. For example, if you have two FTP servers in higher availability, you will do another kind of action on them, addition to them, saying that if one of them is available, then the availability of the service is high, even though you can get a warning because one of them is not available. So you have limited capacity, for example, but the same data and the same service is up. If the two FTP servers hold different data, then you want to do an ad between them, showing that, yes, the FTP service is up, but there's a big problem because part of the data you want to serve is not available. This is then passed to the computing engine then is connected with the web app, which offers all these results in a number of different boards which the web UI uses in order to produce the dashboards we wanted. Of course, all of the components are intangible and all of the components use public APIs or the messaging service so that we can, for example, offer a solution if someone wants to use their own portal, for example, they can simply import data from the API, but we'll talk about this in the use case we have later on. I'm sort of mentioning the components we have. I will go through them again briefly. It's the one during engine that acts like a broker or the crown job and executes the jobs and collects the results, which is then sent to the messaging service. We have a configure. We will probably need to have a configuration wide so that we can define all these metrics. What is the source of topology? What are the metrics you want to do? What are the profiles you want to use and give to the computing engine the full, let's say, blown diagram? What needs to be done in order to get the results? You need to have a computation engine that is able to do all these computations and use the metrics and provide, calculate the status and availability and availability results. At the same time, it's also integrated with the alert engine. If it sees a failure somewhere, it will spawn the alert mechanism, the notification mechanism that can be integrated with either email, Slack, or whatever the end channel appears to be. We do need a web app because we collect data for quite a big period of time. Providing an API so that you can see the results throughout time and be able to ask for more or any computation, for example, if there's a well-known problem in an internet provider, for example, you can ask for some parts to be excluded due to that fact that they need to do something beyond your control. Then, of course, everybody wants to see a nice web interface where all these results are presented in a very good manner. In order to take much time from you, I will go then to the Interoperability Guidelines and what we foresee as use case scenarios in order for either a service provider or an infrastructure or a third party to be using this AOS monitoring service. The first and the initial use case we have already started working on is the use case where two different facilities, for example, EGI or EUDAT, want to combine services and have a combined view of their services. This can be done by the computation agent where the two tenants can be merged and provide one merge report. Similarly, the other use case is the use case where a service provider wants to join and be a monitor his or her services while not willing to go for a full blown tenant for their own idea of this will simply mean that they need a provider topology and provide the probes or the metrics they want to check against the service. So we need to define these and what are the calculations we need to do on the services knowledge provider results and then it can be combined on their own. I went through the first two of them. The third use case is that somebody else wants to use the monitoring data. This could be, for example, that the AOS portal wants to drill in and use the monitoring data we collect and present them somewhere else or that a research infrastructure that is using a part of the AOS services wants to pick up the specific results or the raw performance data and use them in their own portals or in their own mechanisms so that they can also take into account the results of the baseline services they use from here so that they can understand why their own services on top of the baseline, for example cloud computer, data storage, data services are operating. Short question, how many slides do you have? This is how Argo, the current service we have in AOS Hub actually implements this specification. You can ask me more questions later on if you want but in essence you can expect that all the whatever I described as the specification is already implemented by Argo and on this slide you can see some examples of the current dashboards we already have. One of them is for the EGI, one of them is for EUDOT and the last one, the newest one we have which is still in developed instance is the AOS portal one which is a new tenant that uses a completely different topology. I use this screen so exactly because I want to show that we don't really need to be taking a full-blown topology like CokeDB or DPMT, we can use a smaller level of flat topology and still be able to produce results according to the metrics they have and that is all from me. I hope I was fast enough for you Mark. There is also training for tomorrow. Yeah, one last thing, there is a full-blown training that we will demonstrate all these tomorrow. Yeah, tomorrow morning. Okay, thank you. Then I want to go to the next one and that will be about a community use case which is from Opelkost. Joao, can you switch? Can we switch to Joao? Okay, yes. Okay, thank you. Yes, we can see the slides. Thank you, go ahead. Hello, my name is João. I work at Leneca in Portugal as one of the developers of the Opelkost service. Today, me and my colleague, Samuel, are going to tell you a little bit about our adventure integrating Opelkost with AOS resources and services. But before we get into the technical details, let me just give you a brief overview of what the service is and what it has to offer. In a nutshell, Opelkost is an operational forecast service for coastal waters, a bit like the weather predictions that everyone knows, but for coastal water bodies. You may ask, why do we need such forecasts? So they are useful for a bunch of stuff, things like anticipate contamination events and support emergency actions, support water economy daily tasks and recreation activities, guide management to minimize risks in the coastal areas, among others. The Opelkost service assembles on human circulation forecast systems for selective coastal areas and generates daily forecasts of water levels, wave parameters, 2D and 3D velocities, and 3D salinities and temperatures over the region of interest for 48 hours based on numerical simulations of all the relevant physical processes. So we have a little bit of statistics and the providers. Next, a little bit about the web app. The service has three components, a configuration assistance, which allows the user to set up a new forecast step by step. Here, he only has to provide a mesh of the region to simulate specifying the forksings and a few other parameters, and that's it. Then we have the forecast manager, which allows the user to check and manage his or her own forecast systems. And then the last one, the viewer, which allows the user to check the results and see how the results pair against real data. And now my colleague Samuel will present some details about the infrastructure supporting the service. I don't know if Samuel... Yes, yes. So for Opelkost architecture, we start to review the automatic service that exists in the AOS catalog. And for that, we select AGI check-in for users authentication, AGI cloud compute to provide compute resources for front-end and back-end, AGI cloud container compute using UDocker, AGI output compute to run the simulations, and also AGI workload manager. This also uses the interoperability guidelines provided by AOS core services, as mentioned in the presentation before. So for the next slide, I have here some integration challenges that we have from the current service and to integrate them with the automatic services. So the problem here was to integrate with the federation. So we need to review the authentication and authorization services. For that, we use federated authentication using AGI check-in for Opelkost users. Also, we need boxy certificates for grid services, where we use robo-certificate. Also, we need federated authentication to access data repositories, such as UDocker. Then, we need to do the service models creation that this stands for, try to do the service deployment using infrastructure as a service into resource providers, using RAC REST full API to allow it integration to software. This is also the first case, requesting the service from AGI. Also, data transfer between cloud and grid environments, using storm webdav with proxy certificates. So for open-cost cloud, as you can see in the image on the right, so the dashed rectangle there, we need to deploy all the services for open-cost environment using virtual machines in the cloud. Then we need to adapt the software that was previously only deployed in the cloud to work with the grid. For that, we need to create an image that you can see in the image on the right that needs to be integrated with CVMFS, so we can deploy it to the grid, and have the jobs, so all the computation task works, submitted through Dirac to the grid. In the next slide, for open-cost grid, we also need to define the pilot to prepare all necessary environment to run the work in the grid side. Also, we use UDocker to provide the required environment to run the software and also loads the image, and this provides the better integration for software demands into the worker nodes environment. So in the next slide, I have also here another issue that is related to data, so we need to transfer data between the cloud and the grid, and also we need to share the products of the computation. So we need to transfer data between the cloud and the grid, and also put that data in a repository. For that, we use Storm, as I mentioned before, using Weblav that allows to do the transfer between the cloud and grid, and all data between the computation and the registration in the cloud side, and this uses some different authorization models. We have in the grid proxy certificates authorization, and in the cloud, we have federated authentication and authorization using cost. So for here, we need to link them to a data repository, the data, for instance, using a solution like V2Share from UDot that use RESTful API services that are integrated with AGI check-in, and also submit the jobs into the grid. This kind of solution tends to pass through the back end that you see there in the left of the image that do all these kind of translations. So there is also another problem that we need to solve that is about Dirac. In the next slide, we need to solve some limitations that exist in Dirac API. So they're internal dependencies inherited by API requirements that break the open-core software, other maintenance tasks to follow supported services releases, and these kind of limitations we could solve them using Dirac RESTful API that provides a better abstraction, only requiring to follow the specification, and flexible software development independent from Dirac service deployment. This is just kind of deployment that we show here, and that allows us to tackle some problems and allow better integration for future releases. So now I pass the message to my colleague, Joan, that we'll explain some details about this. And the presentation, let me just share as a NAOS service developer some advice and tips that may be helpful. So regarding EGI checking, it can be very useful to offload the responsibility of keeping some sensitive information. Regarding Dirac, having a proxy broker that handles the Dirac submission jobs adds a bit of complexity, but at the same time isolates Dirac software dependencies and interfaces, and allows to manage sharing information like authentication tokens and resource usage cleanly, and to abstract much of the internal details of Dirac for users and clients. The Dirac web portal can be very useful to monitor executions within the Dirac itself. And the use occur, which is a non-root container engine that allows us to provide the necessary software to run our simulation model in resources which weren't previously set up to have all the dependencies needed to run the software. And that's it. Thank you. Okay. Thank you, Charlie and Shangron. I hope that the interoperability guidelines were very useful. Maybe you can comment on this. So regarding the integration, most of them or at least some of them weren't available at the time we were doing this kind of integration. I don't know, maybe someone can answer a little bit today. Yes. So the tackle here about the instructions were more like about understanding how we can use the automatic services and integrate them and provide them in the architecture. So we need to divide this presented before in three kind of approaches. So we need to review the automatic service that we need to integrate. Then we have also some common functions that we need to pass in the middle. And also the context of the services. This is the kind of challenge that I showed as some of the challenges like integrating the authentication, authorization and the computation. And these kind of things is what we need to understand when we start to integrate the services into Welsk automatic services. Okay. Thank you. These were all the presentations. Now I want to switch to Slido. Sarah, can you switch to Slido? Yeah. Because we have still very limited time, I want to skip the poll and just focus on the questions. That is okay. The first question was the highest thumbs up. Do you expect the automatic service developers to organize their services into building blocks or only Federation access and enabling service will be organized in that way? Diego, can I ask you to provide an answer on this? Yes, sure. In general, the framework that we have developed is for the type of services. So also for the automatic services. In our work here at SCAP, also considering the expertise within the project, we decided to focus mainly on the Federation and accessing services, the common services, but the framework can be also applied without any issue on the automatic services. Obviously, as the services should be split in building blocks, depends on the specific thematic area. So we need the people with the expertise on the thematic area to identify and define the building blocks. Thank you. Welcome. I can compliment maybe on this is that within Eelsk, you can use Eelsk as a channel to promote which standards you use, but then you have to describe a little bit as how you want to promote those for different type of functionalities and those are then more aggregators in the building blocks. Another question is also from Duzan. So if a service is using its own help desk, integration with a central Eelsk help desk will be required during the onboarding process. I can answer this by myself. It is not mandatory to integrate your help desk system with the central Eelsk help desk system. It is optionally and the anthropographic guidelines will then provide more information about how you can integrate your help desk with the central one, which are the guidelines and procedures for doing this, but we also provide different options for different levels of integration. So it is not mandatory. Mark Poitier, an impressive plan, very top-down though, missing some local standalone vision, portal standard, dataset format replacing CSV, GWF and some others, and whatnot, making data, edit, analyze tooling openly readable across all domains. GWW3C and OKRM has part of the solution. Maybe it can be shown that it is top-down, but it is not to be top-down because it is really to be about bottom-up. So that we open that defining those interoperability guidelines should come and in collaboration with all researchers, research infrastructures, the infrastructure providers, to define what are the useful building blocks, but also what are the interoperability guidelines for integrating and making use of those building blocks. So it is really to be a very collaborative work to define those guidelines instead of that it is defined from top and then you have to use this. Therefore it is also the definition that it is a reference architecture so that you have all the freedom of making use of those guidelines, but if you have your own standards, it is still allowed that you have those standards by your own, so it is not mandatory. Therefore it is also your proposal to have a reference architecture. Mark, sorry, maybe I can also add something on this question. Very quickly, I fully agree with what Mark said, and this bottom-up approach can be also seen in the technical specification building blocks we decide to work with. I mean, with an analysis for use cases, we can choose the building blocks that should be properly specified according to the needs of the user communities. So this should balance the effort on the side. That's all from my side. I hope this answered the question to you, Mark. Manuel Bernal, is it possible to actively participate in the design of the interoperability guidelines of the interoperability evolutionary process? As said, yes, and I think that is also one of the purposes and the scope. If you look at how we discussed this, for example, in the proposal of preparation for the ESO tree, we want to set up a very similar model, for example, and we have been looking to this from the ESO working groups and the architecture working group, where we have a flexible model for defining task forces, for defining those interoperability guidelines, and that should be open to anyone who wants to participate. Lucian, how easily you can extend the current monitoring to cover some aspects of the repository monitoring currently produced by OpenDoor, OpenAir, etc. Is it expected to further develop all the monitoring might to go into this direction? Kastas, can I ask you to comment on this? I think Zemiz was prepared to answer this question when she showed it. The monitoring service is flexible enough and can accept and compute different sources, so I don't think a really huge problem, but although we don't know exactly how the repository monitoring is in details, I think that we could find a solution to a part of it. There is also training tomorrow where we can, in the afternoon at 2.30, so if Lucian wants, we can discuss it also there. Okay, thank you. I will add that to the URL to the slide though. I think that I will go through the four questions which are still available because we are running into the deadline. Another real world issue, but I'm up, I see on the ground that we plan for data to be linked at global level, but people lack the tools, knowledge, vocabulary to describe and document the nature of the data. Schema semantics, units, values, procedures to be integral, reusable. Yes, a lot of those knowledge is still lacking, but I think this is to have those interoperability guidelines for different levels, also not only just for the technical, for the services, but also for the other levels as on data, so that you have defined frameworks for doing this and promote those frameworks. It should approve, but this probably will take time to improve to set those guidelines, but also the adaptation of those guidelines will take some time, but I think the first start is for a starter with defining guidelines. A question from Raymond at Diego. In addition to the technical side, another important comes from policies and procedure for operating on help desk. Communication, resolution, time for a ticket, is this to be addressed within the documents? There you go. Yeah, no. I can say something, maybe Pavel can compliment. The technical specification is focusing on the technical aspect or in the architecture and the integration from a technical point of view. We have a parallel effort on defining also the policy and procedure for operating on help desk. This is something Pavel showed in his slide when he presented the difference, the support unit structure. I don't know Pavel, do you want to add on that? Yeah, that's true. The procedures and policies defined in the ESRM process and followed by the ticket management daily. This is not directly addressed in the specification, but it's a complementary information defined in the process definition. Yeah, right. So, technical specification was complemented by the relevant process of the YOSCABO service management system. Thank you, Pavel. Okay. This was a message from Kostas to find, to see where you can find the guidelines, the realty guidelines. Then we have a question from Volker Boenstra to add to March which is a question, how does this stop down approach compared to the vision of creating a web of Caroline when described just the day. I think that we try to be as open as possible to allow as many of different opinions and different views. But during the discussion that we come to some progress, so that what would be the best plan was to adapt for the future. Multiple guidelines can be provided, but also multiple visions can be defined on this. But I think that is also part of the collaboration for the bottom-up approach that everyone can contribute to see what is the best direction you can go to. But now, how is the ticketry direction implemented? I think that is at the moment very specific to technical implementation. I would propose that this should be part of the interoperability guidelines. I think the last question was in terms of the adaptation of standards and well-known APIs as part of the EOS interoperability guidelines. How are these standards and APIs chosen? Is it possible to get an overview of standards and APIs to use for proper integration with EOS? How to follow further decisions and developments? I think this is part of defining those guidelines and the choosing of which standards and APIs best to promote through EOS is part of the process of the discussion or the collaboration so that you can come to an agreement which are the best standards and APIs to promote. And that I think is also part of the work we try to do within ESCAP, but also in the future, but also within, for example, the ESCAP architecture work, which is currently developing guidelines, for example, on the PDs and the policies, but also for the AI. I think this is the last question for Milan. How do you resolve the capability of monitoring service? If you will have a lot of services, there's a lot of monitoring firewalls. Krasas, Timus, who is the best of you to answer this scalability question? I can answer this. It's rather easy. The design of the current architecture of the monitoring service is by design scalable, and we can add more compute engines, more monitoring engines, or more of whatever component might be needed. And this can allow us to scale out and have different, a lot more, say, if you add more monitoring, you can have more probes. If you add more, let's say, power to the compute engine, you can do more calculations at the same time. Now, taking this into account, the scalability, as I said, is built in the design we've done. On the other hand, monitoring, as we see it, at least at the AIOS level, should not care about disk space or things like that. This is fabric monitoring that each service provider should do on their own. We don't aim or we don't foresee, at least, that we were going to do what is called fabric monitoring. If, for example, there's enough disk space in the system, if there is enough memory in the system, or if there is enough connectivity in the system, as I said in my presentation, what we do is we monitor what the user will see. If your first service which doesn't have enough capacity for the point of view of the user, then the only thing we can say to you is that you don't have enough capacity for us. It's not up to us to do health check monitoring if the CPU has a greater load in your system or if the disk is full. It's the main, our focus is to do what the user does in your system, and I report on that. For this, it is more functional monitoring if the service does what you do, but it is not the local monitoring if the service is operating correctly as or performing as you want. Yeah. Okay. Thank you. This was the final question. Sorry to be a few minutes late in this session. I want to thank all presenters for their contributions, and I want to thank you all for attending this session. Thank you. I think we can conclude this session. Thank you. Thank you. Bye. Bye! Bye! Bye! Bye! Bye! Bye! Bye! Thank you, bye-bye! Bye! Sara, I cannot assume that you will close down the session. Yes! Diego, you can stop the recording. Sara!