Powered by Indico
v3.2.7
MINUTES 24/10/2011 Attendees T. Ferrari, P. Solagna (EGI.eu) D. Nilsen (NGI_DE) M. Radecki, Rafal Kluszczynski, Krzysztof Benedyczak (NGI_PL) ** INTRODUCTION T. Ferrari introduces the topic of the meeting and the scope of the workshop which will take place on the 01 of December to discuss the future of the information discovery service for EGI, and to provide a clear set of requirements to the technology providers. Currently top-BDII provides both dynamic and static information about resource centres (installed capacity, versions of software deployed, service end points, etc.). A service that provides similar capabilities and interoperating with multiple services (gLite, ARC, UNICORE, GLOBUS) is currently not existing. Currently top-BDII support service discovery and various operational workflows. UNICORE on the other hand is based on a registry, which provides minimal information. Dynamic information is published directly by the service end-point. ** Status and plans of expansion of UNICORE Resource Centres (NGI_DE, NGI_PL) *** NGI_PL (MR) Currently 5 are the sites that funded by PL-Grid. These contribute about 95% of the resources in Poland. In addition to these 3 additional resource centres exist. These three are not directly funded by PL-Grid. The 5 funded sites have the committment to make their resources accessible both through gLite and UNICORE. The remaining 3 have the choice and currently only deploy gLite. Currently in PL_Grid the choice of which middleware to deploy is left to the application client. TF: EMI is planning the implementation for a gLite/UNICORE harmonized CE interface KB: it is unlikely that user communities are willing to run on gLite resources if the interface exposed only provides a subset of the functionality that is provided by UNICORE sites MR: Information about UNICORE resources is generally also available in top-BDII as UNICORE sites also expose a gLite interface, typically exposing the same hardware. However: - this is unreliable and approximate, e.g. UNICORE may expose different queues, subset of the cluster, same about gLite. This situation do happens in practice. - information about storage resources is not available (as these are UNICORE specific and are not published in BDII). UNICORE is not using srm. KB: harmonization plans are in place to adopt srm in UNICORE *** NGI_DE (DN) D-Grid is the infrastructure that is using UNICORE. These resources use the registry service of UNICORE for discovery. The WLCG sites are all gLite based and rely on BDII. Integration of UNICORE has been enabled in GOCDB. It is expected that about 20 sites from D-Grid will join NGI_DE by end of 2012. TF: GOCDB cannot be used for dynamic information DN: Unicore sites are being used as separated resource centres. The use cases from a user point of view haven't been extensively discussed. ** Publishing of static and dynamic information of UNICORE Resource Centres: needs? DN: it is likely to be a requirement as NGI DE sites will be heterogeneous: only exposing one stack (gLite vs UNICORE), or exposing both. Having harmonization is desirable by the use cases haven't been defined yet. TF: does NGI_DE have tools that collect information from both top-BDII and other registry information sources? DN: not aware of these tools MR: it would be good if the unicore user community could be involved in the discussion to understand their requirements ACTION on Dimitri to collect information from regional user communities active in Germany and D-Grid KB: users deploy graphycal interfaces for workflow composition, it is unlikely that they would be willing to change the application layer. TF: the harmonization activities will be at the middleware layer and should be hidden at an application layer. The harmonization of CE inteface started in 2011 and initial (partial) release is planned for EMI 2.0 ** information discovery for access to HPC+HTC Resource Centres (e.g. MAPPER) TF: How is information discovered in the QcG broker used for mixed HTC/HPC applications such as the multi-scale simulation apps of MAPPER? KB: more information shuld be collected from the experts, however it is likely that information is collected directly from the service end-points. ****************************************************************************** ** USE CASES // Draft General EGI.eu/NGI use case: 1) discover software versions deployed in the infrastructure to determine the sites and the amount of these deploying a given version. This is necessary in various use cases: - Critical vulnerability affecting a specific version of the software - to discuss software support calendars with the providers - to support sites with the de-commissioning of obsolete deployed software - to understand the uptake of new middleware updates 2) use a site-level registry to record NGI_PL Use case: . keep track of installed UNICORE storage resources. NGI_DE Use case: . collection of information through existing tools from both UNICORE and gLite sites ACTIONS (TF): to provide minutes and draf a list of use cases based on today's discussion ACTION (NGI_PL and NGI_DE): to elaborate on the discussion we had today and see if a consolidated list of requirements exist ACTION (NGI_DE): to collect use case information from the regional UNICORE user community COMPLEMENTARY INFORMATION (M. Radecki, 07 Nov 2011) The change in the registry architecture won't influence UNICORE client-side (and also *-middleware clients) *only* if a new service is going to be developed and added in parallel to what is available now. If the registry system is going to be reorganized, clients will need to be updated too. There is a service in UNICORE which collects the dynamic information from the sites, caches them and make available through a WS interface. This service is called GRIS (GRid Information Service) and is deployed (always) together with UNICORE Service Orchestrator (the UNICORE broker or WMS counterpart). The currently used service is bit inflexible but the new upcoming (hopefully quite soon) 2.0 release should provide all required features and also will be easily extensible. Some of the UNICORE components publish their version already, the rest will from the next release.