MINUTES 2012-07-06 =================== Tiziana Ferrari Stephen Burke Ilya Saverchenko Emir Imamagic Peter Solagna Tylo SUMMARY OF MEETING ================== (I) EGI will provide a EGI GLUE 2.0 profile for discussion at the end of August, with the aim of finilizing the profile at the TF12 after discussion with EMI and IGE. The profile will include compute and storage services (II) IGE will work on GLUE publishing for GRAM, gridftp and GSISSHD, with GSISSHD info provider already available from EMI (VOBOX) (III) IGE will support GLUE 1.3 (both static and dynamic information) for GRAM5 only. For all the other services the target is GLUE 2 only support =============================================================================================== IGE introduction on information system plans ============================================ summary of plans presented at the previous task force meeting: IIS capability schema: developments started with TERAGRID, but other schema can be integrated IIS _ BDII integration: BDII is ldap while IIS is XML --> BDII information system for GLobus in EGI How can information be propagated? Q1: What kind of information has to be published? ================================================= Sep 2012 (TF12): finalization of EGI GLUE profile SB: is development from CREAM going to be reused? it can be used automatically for GRAM IS: we are using existing information providers as a reference, but implementation work specific to GRAM interface still needed SB: description of computing service (batch system) is decoupled from end point (CREAM vs GRAM), the batch system part can be reused SB: if a batch system is not supported by CREAM this needs to be re-developed TF: who is responsible of the information providers? NGI_DE/D-Grid (LRZ) GRAM5 inform providers from D. Groep (for static information) Q2: What info providers are needed from globus services to feed the local instances (e.g. GRAM, gridftp, other services?) ================================================= gridftp: publish end-point (easy) or publish more as a storage element (this is more complex, includes disk space, how much it is used) IS: gridftp is a SE not just a gridftp end point gfal is now being re-written and it is not clear if a classi se is still supported EI: usage patterns may be different for gridftp SE The EGI profile document will provide guidelines for both GRAM5 and gridftp Profiling requires the definition of: - what is mandatory, what is optional - for what is mandatory, what are the semantics of the attribute require The internal organization of a service may make publishing of some attributes difficult, this is why discussion with developers is needed. Rendering of schema information is a different problem. For an attribute/object the rendering in xml has to be defined, but the attribute/object itself is fixed. Discussion of enumeration types will happen within EMI and EGI will adopt the proposal. GSISSHD: information published about GSISSH in VOBOX, the information provider can be reused VOBOX is a composite service. The information provider is from S. Burke ACTION (IGE): to check the information provider (it's just about publishing an end point) myproxy: it's publishing in BDII and Stephen is responsible, it comes with core BDII which provides service publisher and configuration, which includes myproxy and gsisshd RLS: not a priority for EGI at the moment as no production instances are currently registered in GOCDB. ACTION (Ilya) to check RLS support plans of IGE Q3: Avoiding GLUE 1.3 support would be preferred ================================================ Publishing side: some glue 2 info from 2010 available, but EMI 2 only provides full GLUE2 publication for compute and storage, at the moment we don't have EMI 2 in production Publication: it will take a few months, so roll out of glue 2 services will take time What is being published also has to be checked WMS: there is no complete GLUE 2 support right now For storage gfal: EMI 2 is supposed to support it in full For the next year or so we will in be in a beta test IS: what is the effort required to also support glite 3.1? SB: can CREAM/lcg-ce work to be reused? IS: only static information is published in glite 3.1 (no dynamic information) The bigger effort is needed for the dynamic information Discussion on sustainability of these developments in IGE and of BDII sustainability after EMI ACTION (IGE): look at glue 1.3 support only for GRAM5 and esisting code to be reused. Gridftp will only publish in GLUE 2. AOB === PS: EMI 3 will allow direct plushing into top-BDII (usage of multiple resources per site instead of the single site bdii), which means no site-BDII in GLOBUS sites will be needed at that point. SB: a site can publish through another site BDII (e.g. GRIF with 6 sites feeding into 1 site BDII) ----- end