tag:blogger.com,1999:blog-55268307500340298262024-03-13T21:31:51.312+01:00Steve at CERNA log of the items I'm working on at work during my time at CERN.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.comBlogger116125tag:blogger.com,1999:blog-5526830750034029826.post-46037701899780155202009-09-17T17:52:00.002+02:002009-09-17T18:03:16.676+02:00Next Week EGEE 09Next week is of course <a href="http://egee09.eu-egee.org/">EGEE 09</a> in Barcelona. As a warm up the EGEE SA1 OAT sections a sneak preview.<br /><br /><object height="364" width="445"><param name="movie" value="http://www.youtube.com/v/PADq2x8q0kw&hl=en&fs=1&border=1"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src="http://www.youtube.com/v/PADq2x8q0kw&hl=en&fs=1&border=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" height="364" width="445"></embed></object><br /><br /><a href="http://www.youtube.com/watch?v=PADq2x8q0kw">http://www.youtube.com/watch?v=PADq2x8q0kw</a>Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-51708339849459150572009-03-23T08:06:00.009+01:002009-03-23T11:11:45.642+01:00Installed Capacity at CHEPThis week is <a href="http://www.particle.cz/conferences/chep2009/">CHEP 09</a> proceeded by WLCG <a href="http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=16861">workshop</a>. I presented some updates on the roll out of the installed capacity <a href="https://twiki.cern.ch/twiki/bin/viewfile/LCG/WLCGCommonComputingReadinessChallenges?rev=5;filename=WLCG_GlueSchemaUsage-1.8.pdf">document</a>. It included examples of a few sites that would have zero capacity if considered under the new metrics. <iframe src="http://docs.google.com/EmbedSlideshow?docid=ddvzft29_67d9sdncfj" align="right" frameborder="0" height="342" width="410"></iframe><br />Sites should consider taking the following actions.<p></p> <ul><li>Check <a href="http://gridmap.cern.ch/gm/#topo=tiers&layout=tc&vo=&serv=Site&sitenames&si2k&strict">gridmap</a>. In particular the view obtained by clicking on the <i>more</i> label and selecting the "size by SI00 and LogicalCPUs".<br /> </li><li>Adjust your published #LogicalCPUS in your SubCluster. It should correspond to the number of computing cores that you have.<br /> </li><li>Adjust your #Specint2000 settings in the SubCluster. The aim is to make your gridmap box the correct size to represent your total site power.<br /></li></ul>The followup questions were the following. Now a chance for a a more reflected response.<br /><ol><li><b>Will there be any opportunity to run a benchmark within the <a href="https://twiki.cern.ch/twiki/bin/view/EGEE/WorkerNodeConfiguration">gcm</a> framework?</b><br />I answered that this was not possible since unless it could be executed in under 2 seconds then there was no room for it. Technically there would not be a problem with running something for longer, it could be ran rarely. We should check how the first deployment of GCM goes, longer tests are in no way planned though.<br /> </li><li><b>What is GCM collecting and who can see its results?</b><br />Currently no one can see on the wire since messages are encrypted. There should be a display at <a href="https://gridops.cern.ch/gcm">https://gridops.cern.ch/gcm</a> however currently it is down but once there it will be accessible to IGTF CA members. For now there are some <a href="https://twiki.cern.ch/twiki/bin/view/EGEE/WorkerNodeConfiguration">test details</a> available.<br /> </li><li><b>When should sites start publishing the HEPSpecInt2006 benchmark?</b><br />The management contributed "Now" which is of course correct, the procedure is well established. Sites should be in the process of measuring their clusters with the HEPSpec06 bench mark. With the next YAIM release they will be able to publish the value also.<br /> </li><li><b>If sites are measuring these benchmarks can they the values be made available on the worker nodes to jobs?</b><br />Recently the new <a href="https://savannah.cern.ch/patch/?2758">glite-wn-info</a> made it as far as the PPS service. This allows the job to find on the WN to which GlueSubCluster it belongs. In principal this should be enough, the Spec benchmarks can be retrieved from the GlueSubClusters. The reality of course is that until some future date when all the <a href="https://twiki.cern.ch/twiki/bin/view/EGEE/WNWorkingGroup">WNWG</a> recommendations are deployed along with CREAM also then this is not possible. So for now I will <a href="https://savannah.cern.ch/bugs/?48408">extend</a> glite-<br />wn-info to also return a HepSpec2006 value as configured by the site administrators.<br /></li><li><b>Do you know how many sites are currently publishing incorrect data?</b><br />I did not know the answer nor is an answer easy other than collecting the ones of zero size. Checking now of 498 (468 unique?) SubClusters some 170 of them have zero LogicalCPUs.<br /></li></ol>On a more random note a member of CMS approached me afterwards to thank me for the support I gave him 3 or so years ago while working at RAL. At the time we both had an interest in making grid work. He got extra queues, reserved resources, process dumps and general job watching from me. It was the fist grid jobs we had approaching something similar to the analysis we now face. Quoting the gentleman from his grid experience and results using RAL he obtained his doctorate and CMS chose to use the grid.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-23996721981027607212009-01-29T09:58:00.005+01:002009-01-29T10:47:27.555+01:00SA1 Nagios Deployment UpdateThe EGEE SA1 Nagios bundle was released yesterday with significant updates.<br /><ul><li><span style="font-weight: bold;">GOCDB Integration</span>: A list of Sites can now be collected using the <a href="http://goc.grid.sinica.edu.tw/gocwiki/GOCDB_Technical_Documentation">GOCDB's new API</a>. In particular a list of sites in a ROC or in a Country can be monitored extending the previous LDAP filter on Sites.<br /></li><li><span style="font-weight: bold;">GOCDB Downtimes</span>: Downtimes entered in the GOCDB are now also pulled into and inserted as NAGIOS downtimes for your services.<br /></li><li><span style="font-weight: bold;">HGSM Integration</span>: HGSM is the SouthEast Europe equivalent to the GOCDB.</li><li><span style="font-weight: bold;">NDOUtils Installed</span>: <a href="http://nagios.sourceforge.net/docs/ndoutils/">NDOUtils</a> sits behind NAGIOS and fills in a MySQL database with NAGIOS's configuration and metric and test results.</li><li><span style="font-weight: bold;">New SRM Tests</span>: These mimic some of the logic of the existing SAM SRM tests. The eventual replacment to the SAM SRM tests. In NAGIOS speak we now have an active check that submits scripts and returns passive results for each of steps of the lcg-cr, lcg-rep, lcg-del seem before.</li><li><span style="font-weight: bold;">NSCA Installed</span>: Especially for the case where two nodes are used, a NAGIOS node and NRPE triggered UI then passive test results are submitted back via <a href="http://nagios.sourceforge.net/download/contrib/documentation/misc/NSCA_Setup.pdf">NSCA</a> from the NRPE-UI. Well almost - <a href="https://savannah.cern.ch/bugs/?46378">Bug</a>.</li><li><span style="font-weight: bold;">New BDII Checks</span>: These are the checks taken directly from the gstat2 work but now running against your services.</li><li><span style="font-weight: bold;">New <span style="font-style: italic;">msg-to-queue</span> Service</span>: Running on a NAGIOS box this subscribes to externally executed test results for your Site or ROC from the ActiveMQ messaging system. Currently nothing is actually coming in but much of the infastructure is now there.</li></ul>As before <a href="https://twiki.cern.ch/twiki/bin/view/EGEE/GridMonitoringNcgYaim">installation</a> can still be done completly via YAIM both for a site or ROC. New packages can be followed for <a href="http://www.sysadmin.hep.ac.uk/rpms/egee-SA1/sl4/i386/repodata/">i386</a> or <a href="http://www.sysadmin.hep.ac.uk/rpms/egee-SA1/sl4/x86_64/repodata/">x86_64</a>. And of course <a href="https://savannah.cern.ch/bugs/?group=sa1tools">bugs</a> and <a href="https://websvc03.cern.ch/listboxservices/simba2/listeditor.aspx?list=wlcg-monitoring-discuss">feedback</a> are always welcome.<br /><br />The update contains work from Emir, James, Laurence, Konstantin and myself.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-43932997887682059482008-10-17T11:09:00.003+02:002008-10-17T11:16:16.723+02:00Top BDII Publishing RevampI have updated the <a href="https://straylen.web.cern.ch/straylen/topbdiis/topbdiis-prod.html">topbdii summary page.<br /></a> It now includes an historical element as well so you can see the individual site inclusions in each top level BDII over a period of time. There are clearly some topBDIIs which are <span style="font-style: italic;">flakier</span> than others represented by vertical blue lines and some sites are dropped at times by all BDIIs represented by horizontal blue lines.<br /><br />Also the tables are broken down by BDII version numbers as well.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-58115542495786165902008-05-13T17:21:00.004+02:002008-05-13T22:41:15.463+02:00WNWG Update at the GDB.<div style="float:right; text-align: right;"><br /><iframe src='http://docs.google.com/EmbedSlideshow?docid=ddvzft29_45fd8c9chg' frameborder='0' width='410' height='342'></iframe><br /></div><br />Tomorrow I present an update of the <a href="https://twiki.cern.ch/twiki/bin/view/EGEE/WNWorkingGroup">Worker Node Working Group</a> at the <a href="http://indico.cern.ch/conferenceDisplay.py?confId=20229">GDB</a>. There is now a complete plan that while complicated with updates to information providers, lcg-tags, YAIM and site configurations of YAIM it will work though add complexity. As planned small sites can ignore everything. It seems it can be deployed at its own speed and once done sites can reconfigure to multiple sub clusters in their own time. The presentation has far to much detail for a GDB audience but it's quite a narrow subject. Mostly of <span style="font-style: italic;">interest</span> to site administrators since it is all work for them. The users just get the benefits, better allocation of jobs to suitable worker nodes.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-33133337173432470522008-04-25T22:29:00.002+02:002008-04-25T22:46:12.504+02:00Interesting GGUS PostsIn the last two or three weeks <a href="http://www.ggus.org/">GGUS</a> is now serving an experimental <a href="https://gus.fzk.de/rss_test.php">rss</a> feed of new posts. Watching the posts there is a whole new view on what is really happening at a low level of 1 to 1 GRID operations.... My aim is to post once a week a summary of the three or so most interesting or relevant tickets....<br /><ol><li><a href="https://gus.fzk.de/pages/ticket_details.php?ticket=35783">35783</a>. Tristan Glatard reported that lcg-utils when called with timeout option, -t, rather than timing out gracefully exited with a segfault. In a reality it seems an upgrade fixes this though it is yet to be confirmed.</li><li><a href="https://gus.fzk.de/pages/ticket_details.php?ticket=35798">35798</a>. Earlier in week a gLite release was made that turned out to break certain low level communications between the WN and CE at a globus level. The problem was fixed and released within a working day but with the rush it was never mentioned that the repositories for the different nodes types have been split for the first time. This is transparent if sites follow the install instructions to the letter but I am sure many do not.... I don't. Sites should be told that the glite-WN is currently a break away from everything else.<br /></li></ol>Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-20619387871785168182008-03-20T23:39:00.006+01:002008-12-10T13:17:24.389+01:00Plotting the GlueSiteLocation<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://grid-deployment.web.cern.ch/grid-deployment/graphglue/www/sitelocations/GlueSiteLocationcenter-UK-depth-3.png"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivSi_YxMrkcgJ-dBpd28TOEjI-UWQ1ppuGs295hToFV4tkar_d3mmMuqXwiYvhTZnWas9z04Bu1YsiDZHY63iHbh2Uuw809vdatBmIl3jq3rfPz_xlp0IKrJ46osx7gDoGvnBH9qKht2Gx/s320/GlueSiteLocationcenter-UK-depth-3.png" alt="" id="BLOGGER_PHOTO_ID_5179957937392920850" border="0" /></a><br />I plotted the GlueSiteLocation as advertised in the <a href="http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_my_site_information">GlueSites</a> a few days ago. In fact a quick look over the <a href="http://grid-deployment.web.cern.ch/grid-deployment/graphglue/www/sitelocations/">results</a> shows that the field is filled in well in all but a few cases. Most of the plots are centered on a country with a few "World" ones showing everything. Chris and Steve as a result have an action to fix <a href="http://grid-deployment.web.cern.ch/grid-deployment/graphglue/www/sitelocations/GlueSiteLocationcenter-United_Kingdom-depth-3.png">their location</a> some time whenever they fancy it:-)Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-74910678045137450562008-03-14T20:42:00.003+01:002008-03-14T20:51:35.005+01:00Filling in the GlueSiteThe 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 <a href="http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_my_site_information">review and proposal</a> 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<br />settles down I'll push it through EGEE deployment and YAIM and onto the sites.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-44397162998780215852008-02-25T17:56:00.004+01:002008-12-10T13:17:24.571+01:00Graph the FTS Deployment<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://grid-deployment.web.cern.ch/grid-deployment/graphglue/www/ftschannels/ftschannels.png"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiE9OuZEpD8yvMad_Jxqhu3sq_-J__tZpnrixcRz92nnWjw71RgWV4wxKUjNVknT-fBCFbjtsXEYqn-fagrmKmBsDFGNpNJMmRiiDBrart4RgaJk0u6pdH9knfMF2srCSqDOIeWBel_CkZd/s320/ftschannels-small.png" alt="" id="BLOGGER_PHOTO_ID_5170963475589709202" border="0" /></a><br />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.<br /><br />Again it is another plot that is almost impossible to use.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-7044432242481579182008-02-18T22:56:00.019+01:002008-12-10T13:17:24.737+01:00Graphing Glue<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://grid-deployment.web.cern.ch/grid-deployment/graphglue/"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmSwY1rNYD2o7D2uQBiIRFztWa0cyAAQrZLVP4-SLP06htov6AwTcDkPY-KKIcX1LVReEUsx_1rQ0QrHkvxCvhS7Jz4e7cKnpYzy4eMl5CV-bZXQfbEbxQhgF-nalbcV_r3PuNWNm0BfIQ/s320/RAL-LCG2shrunk.png" alt="" id="BLOGGER_PHOTO_ID_5168797742625668482" border="0" /></a><br />I've been playing with <a href="http://www.graphviz.org/">GraphViz</a> and <a href="http://hypergraph.sourceforge.net/">HyperGraph</a> to draw out the relationships between the objects in the GLUE schema. The <a href="http://grid-deployment.web.cern.ch/grid-deployment/graphglue/www">results</a> 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 <a href="http://gstat.gridops.org/gstat">gstat</a> which is the natural place for them to live once I have improved them. <span style="color: rgb(204, 0, 0);">Warning</span>: 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.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-55142486966199921892008-02-14T16:40:00.004+01:002008-02-14T16:49:54.421+01:00Combined 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. <a href="https://twiki.cern.ch/twiki/bin/view/EGEE/WNWorkingGroupInstallLog">details</a>.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-54307623513095644982007-10-09T20:19:00.000+02:002007-10-09T20:45:02.445+02:00WN Meeting Kickoff Last WeekThe first EGEE WN working group <a href="https://twiki.cern.ch/twiki/bin/view/EGEE/WNWorkingGroupMinutes20070920">meeting</a> 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....<br /><br />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 <span style="font-weight: bold;">SIGTERM</span> -> <span style="font-weight: bold;">SIGKILL</span> window given by the batch system. Francesco's <a href="http://indico.cern.ch/contributionDisplay.py?contribId=32&sessionId=49&confId=18714">presentation</a><br />looks to have considered everything but can check with group if any comments.<br /><br />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 <span style="font-weight: bold;">SIGTERM</span>s.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-85005812598124772932007-09-19T18:59:00.000+02:002007-09-19T19:12:13.337+02:00FTS Release ProgressAt 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 <a href="https://twiki.cern.ch/twiki/bin/view/EGEE/FTSSLC4IntegrationTestInstall01">configuration</a> 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.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-31200465610766003732007-09-14T20:44:00.000+02:002007-09-14T20:59:06.475+02:00Torque 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 <span style="font-style: italic;">exotic</span> platforms like MacOS. <a href="http://eticssoft.web.cern.ch/eticssoft/repository/torquemaui/">Releases</a>, <a href="http://isscvs.cern.ch/cgi-bin/cvsweb.cgi/?cvsroot=torquemaui">CVS Repos</a>. To finish this off I need to close down some of pages hosted at <a href="http://hepunx.rl.ac.uk/%7Etraylens/rpms/torque/">RAL</a> and <a href="http://www.gridpp.ac.uk/wiki/Torque_and_Maui">GridPP</a> with pointers to the new locations. Not bad for a day when I got my notice of contract termination.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-58805940234556669942007-09-10T20:35:00.000+02:002007-09-10T20:42:39.446+02:00Back to School.After a two week break without a single keystroke pressed I've been back for my first day. Big outstanding items are starting a TCG inspired group to investigate and conclude on finding and utilizing individual worker node resources. My first thoughts is that it is all done but there are massive gaps in flexibility of configuration or deployment to achieve it..., it is not done in other words. Other than this the FTM node I've been trying to deploy was rejected from certification for a lack of timestamps in it's logfiles. This is fair enough, I thought it at the time but ignored the problem. Finally the SL4 FTS must be installed, the compilation is there but who knows if it works.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-33112734606563484452007-08-16T09:44:00.000+02:002007-08-16T09:51:38.122+02:00SAM test CE-sft-posix now running.After deployment mistakes and corrections the <a href="https://lcg-sam.cern.ch:8443/sam/sam.py?sensors=CE®ions=Unknown&regions=CERN®ions=France&regions=UKI®ions=GermanySwitzerland&regions=Italy®ions=CentralEurope&regions=NorthernEurope®ions=SouthEasternEurope&regions=SouthWesternEurope®ions=Russia&regions=AsiaPacific®ions=OpenScienceGrid&regions=USCMS®ions=USATLAS&vo=ops&order=SiteName&funct=ShowSensorTests">CE-sft-posix</a> test is now running again. The significant change is that now new SEs that appear pass for the first two weeks. Previously they were guaranteed to fail for the first two weeks. The results look promising in that out of 287 CEs tested today 69 or so look to fail. This includes the 10 or so CERN CEs where there may be a problem with the configuration of the atlas-durable and lhcb-durable SRMs but perhaps only with respect to the OPS vo which is probably not well tested. Next step will be to get CERN passing. Need to have my own house in order before proceeding. Following that go through the other failiures to look if they seem fair.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-37811783608128684872007-07-27T21:30:00.000+02:002007-07-28T19:05:50.933+02:00Learning OracleThis week I was on the <a href="http://education.oracle.com/pls/web_prod-plq-dad/show_desc.redirect?dc=D17090GC30&p_org_id=29&lang=F&source_call="><span style="font-weight: bold;">Oracle Administrators Course I and II</span></a>. Apparently because we are CERN and <span style="font-style: italic;">bright young things</span> they compressed the two week course into a one week course. At first it might not be obvious that the course would be directly related what I do day-to-day but I now certainly understand better what the DBAs are doing near by that the FTS uses. In the past they have been easily able to baffle me with the science of blocks, fragmentation, performance tuning, ... The course was given by <a href="http://sysdba.wordpress.com/2007/07/27/seleccion-robustos-from-cern/">Lutz Hartmann</a>, a so called Oracle ACE no less. He was genuinely enthusiastic to teach us and it was all pretty effective. I learned as much as I possibly could in one week so am pleased. I now have one year to do my exams to get the Oracle Administrator qualification. It has to be useful for a post CERN life apart from anything else.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-17367470298332163392007-07-17T23:11:00.000+02:002007-07-17T23:18:33.058+02:00DependentsThis month and either side is the much touted as the <span style="font-weight: bold;">gLite restructuring exercise</span>. The aim is chuck out old code and clean up some of what is there especially looking at dependencies and alike. A review basically. Seems I have been given the LFC and DPM to review which is good, I think they should be fairly obvious. The lack of java makes them easier compared to what it could be. There was some suggestions that the dependencies could be determined from the ETICS system, it is good that the final RPM result is now being used. It is this the final product after all which aim to clean up.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-3075535774169653392007-07-04T20:43:00.000+02:002007-07-04T20:57:24.579+02:00Cardinal Sin of Grid OperationsCERN today committed the cardinal sin of grid operations. They allowed a host certificate to expire for a production service. This took the MyProxy service used by the FTS out for almost 24 hours. The service is a victim of its own success because it had been running itself for the last year without interruption but when it came to it fell between the cracks of responsibility. I've every confidence it will never happen again. At least with this service anyway.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-31782081851804060282007-07-03T21:09:00.000+02:002007-07-03T21:14:59.070+02:00FTM Node is Getting ThereThe new named FTM (File Transfer Monitoring) node made reached a significant point today. All the packages are done including the GridView publishing ones. Also the yaim configuration is done within the new <span style="font-weight: bold;">glite-fts-yaim</span> module. But there seems to be some dependecy problem which is best resolved by just avoiding the problem and moving to SL4. This will be a pain since in the first instance the FTM monitoring will require a different OS to the FTS itself. The dependecies may be able to improved furthur as well. Currently VDT is needed just to provide an openldap client to the BDII plugin within the glite-sd-query tool. Hopefully this can be removed. I'm sure it does not need to be there.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-44742316680151499342007-07-03T21:07:00.000+02:002007-07-03T21:09:28.348+02:00OS MatchingI've now <a href="http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_the_OS_name">published</a> a recipe for matching RHEL3 , RHEL4 OS clones. It's a lot more complicated that it should be and no doubt there will be grumbling but I am happy it is correct.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-74480024540245168822007-06-29T22:58:00.000+02:002007-06-29T23:03:11.573+02:00A Good MatchA busy week this week where I collected more things to do than I completed. There were some complaints from sites that some VOs have asked them to switch of their resources when their SE is not present for whatever reason. It turns out that CMS already have a good query for finding CEs and SEs but it just needs a bit added to to not match CEs when the SE is not published. This should help sites and users a lot if something sensible can be matched. In the process discovered that there is work going on now to write a more intelligent service information provider in the UK. It looks good in principal but I must give some comments before it gets further. On a similar matching note CERN is about to go live with some SL4 resources which means people are now actually worried about matching to versions of OSes. It seems a <a href="https://savannah.cern.ch/bugs/?23284">bug</a> reported as fixed a while back may in fact not be fixed though I need to check this fix has actually gone into latest WMS that was deployed today.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-56599886603688098602007-06-20T17:04:00.000+02:002007-06-20T17:12:58.941+02:00Writing a New YAIM ComponentCommitted and started running a new YAIM component today to configure the new FTM node. It is going to be really trivial to do the code, basically I need to edit some text files and turn some services on so I should be able to handle that. I decided to dig out <a href="http://www.gnu.org/software/ed/">ed</a> for the purpose. It was over 10 years ago worryingly that someone first showed me ed and tried to convince me that if you wanted to edit a text file from a script it was the perfect tool. At the time it seemed far to backwards, today it does indeed seem to be the perfect tool for the job. The initial testing went okay and uncovered several bugs or improvements to be made to YAIM core which are now submitted. The new modular yaim looks like a very sensible idea. It allows me to work on the FTS part without fear of breaking or holding up the rest of the world.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-40616211346119069192007-06-19T17:36:00.000+02:002007-06-20T12:10:57.338+02:00RPMs not ETICS RPMsAfter generating RPMS with ETICS and being generally dissatisfied with them I investigated what others are doing. It seems the order of the day is just to write your own .spec file and tell ETICS not to attempt to do so. It defeats the object of ETICS in that is meant to be package neutral but it decreases my trivial installation instructions from 10 points to just 2 since the rest is handled by a decent package. It should make the subsequent upgrades trivial as well as opposed to a complete reconfiguration from scratch. In fact ETICS is adding features all the time such as recently it now supports the %config RPM directive that is a step in the right direction to make the autogenerated spec files better.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0tag:blogger.com,1999:blog-5526830750034029826.post-79894220461666308302007-06-18T19:02:00.000+02:002007-07-28T19:11:49.531+02:00FTS Upgrade at CERNAfter <a href="https://twiki.cern.ch/twiki/bin/view/LCG/FtsTier0ServerInterventionPlans">careful planning</a> the the CERN FTS servers, production T0 export, tiertwo and the pilot were all upgraded today to version 2.0. It basically went okay and much to plan with completion 10 minutes before the announced intervention period end was reached. In fact two things went wrong. The quattor wrapper for yaim was never tested with the new YAIM, the new glite-FTS2 and glite-FTA2 targets had to merged in by hand. That was my mistake. The other problem still needs investigating but basically huge fragmentation to the production database appears to have (a) made the schema update a lot slower than expected and (b) an index has become corrupted. All in all it looks like although things are working some more downtime will be needed now perhaps longer than the upgrade itself to clean the database up. All in all it makes my life a lot easier, there is now a lot less left that I am managing from before my time getting to CERN.Anonymoushttp://www.blogger.com/profile/08684121414761564302noreply@blogger.com0