This page contains a collection of the answers given by the ROCs/sites to the plans of sites to move to SL4 (or binary equivalent), as requested by SA3.

Asia Pacific

The larger sites plan to upgrade within 1-2 months after the release of SL4 version of WN are released. This however will be dependent on the readiness of the Atlas and CMS to utilize SL4.

Central Europe

The CE sites can migrate to SLC4 as long as VO software is ready to be run on SLC4. We got a response from a site that identified ATHENA (Atlas VO) software as an example which could prevent them to migrate to SLC4. However, we don't know the current status of ATHENA software.

In my opinion it is a general condition that before the migration we need to ensure VO software is running on new OS.


CERN has started the process with several steps: Some special hardware can only run SLC4 (RHES4), therefore they are on SLC4. All new batch h/w is put on SLC4 straight away (hence not usable by the GRID at the moment). SLC4 is the default OS for LXPLUS since end of January. The experiments are tellung us that we can move their share in LXBATCH to SLC4. At this moment, we have roughly 50% of LXBATCH capacity on SLC4. But only ~30% of machines. Some of the older h/w cannot run 64 bit OS, therefore they will stay on SLC3, I do not know for how long. The rest of the machines will be done on an case by case basis, mostly driven by the Service Managers/Application Managers (and s/w availability) of the hosts.


Region DECH: (Survey: Migration plan to SLC4)
  • most large German Swiss sites are ready for SL4 (note "SL4", not necessarily "SLC4"), waiting for deployable middleware with full SL4 support.
  • users are ready for SL4 (no issues so far.)
  • new WNs come with SL4
  • Tier1 GridKA is testing with SL4-compatible SL3 WN packages, currently preparing migration of existing WNs to SL4
  • many sites expressly need 64-bit support, as they already have hardware in place, which is waiting to go into the grid, but cannot fully run with 32-bit.
  • many sites need Quattor templates for MW
  • some small sites can not estimate the migration schedule due to a lack of manpower and the large amount of work with the regular updates


  • DESY "We are not planing to move from SLC3 to SLC4 as we are running plain SL without the CERN extensions. We are very interested in moving to SL4 and our users seem to be ready to use the SL4 environment. In order to start migration, we need a deployable, RPM based release of the middleware (first to be tested in the PPS) that can be installed in a SL4 system without dependencies on SLC. That means that any RPM dependency that cannot be satsified by SL must come out of the middleware repository."


IN2P3-CC: current preliminary plan is: 12 march 2007: part of interactive service in 64bit and 32bit compatibility mode. Some WNs in 64bit mode. 5 june 2007 : significant increase of WNs in 64bit mode. 31 october 2007 : SL3 no longer supported. This is under the condition that SL4 is deployed soon, and stable. Anyway, the newly installed machines cannot be run under SL3.

IN2P3-SUBATECH: two months after availability of SL4 version of the middleware, the site normally should have switched.

GRIF: the large majority of the workernodes is already running SL4. The complete switch could be done as soon as the official support is available (except for some WNs under SL3 just for application migration purposes).

IN2P3-CPPM: part of the WNs already running SL4. Complete switch will be done 1 month after the release of a stable version with Quattor support (the latter comes from GRIF).

IN2P3-IRES: all WNs are already running SL4 in 64 bit mode, but are announced as SL3/i386, as they are compatible. Urgent need to pass officially to SL4 as new material can only be used with difficulties under SL3.

IPSL-IPGP-LCG2: WNs already under SL4.4, one UI being set up. CE/SE/ MON won't be upgraded until a stable version supported by YAIM will be available. Urgent need to pass officially to SL4 as site support will be degraded after July for manpower reasons.

CGG-LCG2: tests for SL4 are about to begin. Waiting for a stable version installable via YAIM. No clear deadline as this depends on the results of the tests yet missing.

Auvergrid/IN2P3-LPC: waiting for stable release with fully functional YAIM. First candidates to be moved will be WN. Other services will need more time. Site will proceed slowly as it had bad experiences in the past, especially when switching from classic SE to SRM.


In February we asked to raise the status of WN on SLC4 because some experiments are requesting its deployment on the production infrastructure; however the lack of rpms and yaim scripts makes it unfeasible for the italian ROC (and other ROCs). See Is there any changes from that discussion?

At the last GDB (3rd March, but also in other previous GDB) this item was deeply discussed, all tier1 were represented and so the VOs. It is also scheduled at the next GDB: The positions of the larger sites is well-known.

At the Operation workshop (19th March) SA3 asked about sites migration plan/timeline, but i think that the sites are the last link of the chain: Are the VOs ready? What kind of migration do they prefer?

Is the middleware ready (with rpms and yaim functions)? What kind of migration scenarios are possible or suggested?

In general almost all sites would like to migrate to SL(C)4 as soon a possible (hardware demands SL4 or newer O.S.), but it is not clear if all VOs are ready. Some site services (not grid) were and will be moved to SL(4) or other O.S. (newer and better update, RHEL 5 is just released).

Who does really need the CERN extensions? we are very interested in moving to SL4 (or CentOS). In order to start migration, we need a deployable, RPM based release of the middleware (first to be tested in the PPS WITH the yaim functions) that can be installed in a SL4 system without dependencies on SLC.

Northern Europe


The support for SL3 ends october 31st this year so there is still time. As for SARA, for the time being we will be running SL on 32-bit hardware so we only need the 32-bit SL4 rpms. These may be native SL4-built rpms of SL3-built rpms which work on SL4. We will not install any tarball distributions. But before we can plan for an upgrade we need to know when the software is going to be released.


In the very near future, we will install some DPM disk servers and UIs with an SL4-compatible operating system: CentOS-4. The DPM disk servers need SL4 to allow disk partitions larger than 2 TB, whereas we need SL4 for new hardware that will run a UI.

However, other servers and/or worker nodes may follow if newly purchased hardware demands SL4. We expect this to become an issue early June. Otherwise, we will follow the requirements imposed by the standard gLite distribution.


No feedback yet

South East Europe

The move to SL4 depend's a lot on when the SL4 compatible release of the midleware will be available, as soon as we have an SL4 release we will evaluate and plan to migrate in SL4, the input we get currently from pps sites is rather discouraging to move quickly to SL4 as the current status of the middleware is not that stable. A rough estimate is 2-3 months after the official release of SL4 middleware so that we can thoroughly test the new mw allong with new version of the OS and other site related software like GPFS. On the other hand, We do have a couple of volunteer sites however that are willing to be some kind of guinea pigs and try the new mw asap.

South West Europe

Here at SWE almost all sites would like to migrate to SLC4 as soon a possible. The main reason is the enhanced support for new hardware. There is already one site (LIP) which uses SLC4 for all their services ported by themselves. Also the 64 bit support war requested.


In general the move to SL4 depends on when the middleware will be available. We need to know when the release will happen in order to plan the upgrade to SL4. Once the middleware has been released sites will catch up very quickly.

-- Main.thackray - 28 Mar 2007

Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r10 - 2008-01-21 - LaurenceField
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback