WiatG further development

Friday 3 Aug 2007, 08:00 → 18:00 Europe/Zurich

1/1-025 (CERN)

Notes from the phoneconf. 1-Aug-07 15:20 - Approx 16:20 Attendees: Ian N(chair), Nick T, Dusan V, Piotr N, Steve T, Rolf R, Pierre G, Osman A, Andy N. A general discussion over the points raised in the various emails took place. Some detail was covered in the issues below with all attendees participating. * relationship between the BDII->GOCDB updates and the Downtime Notification automation. It was agreed that these are for the main part separate topics but the former facilitiates some specific use-cases for the latter. * similarities and differences between what is proposed and Dusan's WiatG project. No conclusions reached here except that there is clearly overlap. * dusan and osman explained some more implementation details for the proposals. * there was general agreement that such comparison information is/would be valuable but Nick and others at CERN felt this was best kept in a separate tool. Rolf raised the issue of some "state" history being necessary for efficient implementation but it was argued by IanN that the GOCDB was not the place to do this. * whether the inclusion of an extra flag/column in the GOCDB tables could be seen as "just" a small change or one that is likely to have wider, longer-term implications. Opinion seemed divided between IN2P3 and CERN attendees with Andy N agreeing that if possible it would be better not to include it. Rolf made the proposal that, since much of the back-end implementation had already been completed without the actual GOCDB update being in place, a phased approach could be taken with the current code being used to publish the difference information on the CIC portal. He cautioned that some consideration of the time to make this available would be necessary offline before making this a firm plan. All agreed that this first stage could be very useful and inform the development of any future plans to be discussed. Actions: 1) Rolf et al to report on feasibility and timescale of above proposal 2) Dusan and Osman should be in contact to make sure duplication of effort and mistakes is avoided.

1 WiatG further development plan - Dusan Vudragovic

WiatG further development plan Brief summary for further development: * BDII web service * sBDII web service * new organization of BDII/sBDII * HGSM (SEE-GRID analogue to GOCDB) web service * Web Applications for visualization of these web services * Alarm dashboard First we have in plan to create BDII web service. It will return a list of attribute pairs as an XML file for a given DN from URL. After this, the web service will be adapted for sBDII and in this way we will be able to query BDII and sBDII in the same way and XML information with the same organization will be returned. The web service can be installed at one server and can be used to query all other BDIIs and sBDIIs, but it will be more useful and faster if it becomes a part of middleware. In that case, in each BDII/sBDII installation Tomcat with the web service will be included. A part from this – full list of attribute pairs for a given DN which represent BDII organization – new user oriented organization of BDII/sBDII information will be implemented in the web service also. This means that one will be able to get reduced information marked as relevant in an XML file from BDII/sBDII (for example only the list of sites with number of CPUs and SE capacities that support certain VO). This will cover current WiatG structure and expand it over new services (MyProxy, localLFC, VO software tags, …), but we will track developer requirements and implement new organization as well. Parallel with this one more web service will be set. That will be HGSM/GOCDB web service and it will provide information about expected Grid resources and it will return XML files with the same organization as previous services. After the skeleton that reflects in web services is done, web applications for visualization will be created. They must be visually identical in order to identify differences between expected and real resources from browser by user. For this purpose AJAX technology will be used as it is now presented in WiatG tool. Comparing results of expected and real resources several things will be checked. First it will be checked if BDII/sBDII work. Then, only observing BDII information some site errors can be noticed, such as “4444 Waiting jobs in the GRIS” and similar. Checking only HGSM/GOCDB, missing important site’s information will be obtained. And finaly directly comparing expected and real resources, differences will be noticed and alarms will be raised. Working names of these tools are “What is at the Grid” and “What should be at the Grid” and these names will be probably changed.