Filling in the GlueSite

The last few days I have again wanted to resolve a given site name as belonging to an EGEE ROC. There are no public interfaces to resolve something that would be useful to so many people including GGUS, the GridPP Real Time Monitor, Operations, Accounting and even the Managers. So I have created a review and proposal to fill the GlueSite object in with well defined information. I have spoken to the WLCG coordinators and will follow up in time with ROC managers, GGUS, OSG the WLCG monitoring working group and any one else I can think of who might be interested. Eventually when something
settles down I'll push it through EGEE deployment and YAIM and onto the sites.

Graph the FTS Deployment

The FTS deployment is of course made up of channels between sites in the EGEE/LCG grid. This plot shows all the channels as queried from the BDII as lines connecting the sites. The grouping of nodes by colours represents all the channels managed by a single FTS instance.

Again it is another plot that is almost impossible to use.

Graphing Glue

I've been playing with GraphViz and HyperGraph to draw out the relationships between the objects in the GLUE schema. The results are interesting but especially for the complicated sites, e.g. CERN, GRIF, RAL,... they are hard to read. There are massive png's, vrml and svg formats. Also the html pages load a dynamic applet of the data. I'll request that they are worked into gstat which is the natural place for them to live once I have improved them. Warning: Some of the png images are huge and will most likely crash your browser. The image here is RAL-LCG2. The orange blob top right is the FTS.

Combined SLC4 and SL4 CE.

As part of the WN working group efforts I've been finishing of a vandalised CE which is now part of the CERN_PPS site. It is two node cluster both of which are WNs. One is also a gatekeeper publishing GlueCE, VOViews and CESEBind objects, the other is publishing two GlueCluster and GlueSubClusters objects. ... To cut a long story short I have a single gatekeeper node which can matched to for either SL4 or SLC4 and the jobs route through to the correct node at the back. It is exactly the same for any GlueSubCluster attribute such as memory for instance. Tomorrow we try and thrash how to get the final steps of this into a release.... It is quite possibly not going to be pretty, keeping things backwards compatible may just not be possible or desirable. details.

WN Meeting Kickoff Last Week

The first EGEE WN working group meeting happened last week. It went well. I had previously thought I knew exactly what the end point would be even if the exact details of migration were not together. The oversight for me was software tags. Namely that for a site publishing non-overlapping SubClusters then a software installation job has to publish software tags in the correct SubCluster. Exactly how you determine which SubCluster you are installing for is far from obvious. No one has suggested a better solution than a configuration file different on every batch worker, there has to be a better way....

From the EGEE conference there was an addition to the group's scope. The group will give help, advice support, approval, something, ... to the WMS wrapper script addition of doing something sensible in grid jobs during the SIGTERM -> SIGKILL window given by the batch system. Francesco's presentation
looks to have considered everything but can check with group if any comments.

One of the consequences of offering users better job matching to WNs is that the sites are possibly going to start killing more excessive jobs dead. A timely addition if the job wrapper now handles the SIGTERMs.

FTS Release Progress

At last the FTM node has actually made it to be released on the PPS shortly. I really don't want to think how long it has taken. Longer than you can possibly imagine. Also this week I tried the SL4 build of the FTS for first time. Installation has been fine but configuration now looks to stuck and will need some new builds to be solved. Most of the problems are changes between gLite 3.0 and 3.1 rather than the OS upgrade. Having said that most of the changes between 3.0 and 3.1 look sensible and bits of yaim configuration are being removed basically.

Torque Maui Builds from ETICS.

Finally got around to pushing maui and torque through ETICS. Bang up to date releases for sl3 and sl4 with i386 or X86_64 are all available. Others like SL5 should now be trivial. The torque build was fairly straight forward where as the maui build does some black magic for the torque dependency it needs. Recently there have been many requests for the X86_64 builds and it is needed anyway for the upcoming official gLite X86_64 WN which is around the corner now. Also the Dubliners have been wanting it for ages to build other exotic platforms like MacOS. Releases, CVS Repos. To finish this off I need to close down some of pages hosted at RAL and GridPP with pointers to the new locations. Not bad for a day when I got my notice of contract termination.