[LU-992] deprecate RHEL5 kernel support for Lustre 2.2 servers Created: 13/Jan/12 Updated: 02/Jun/14 Resolved: 08/Jan/13 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.2.0 |
| Fix Version/s: | Lustre 2.4.0, Lustre 2.6.0, Lustre 2.5.2 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Andreas Dilger | Assignee: | Yang Sheng |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Story Points: | 1 | ||||||||
| Rank (Obsolete): | 4615 | ||||||||
| Description |
|
Deprecate the RHEL5 2.6.18 kernel support for Lustre servers in the 2.2 Lustre release. Maintaining the server and ldiskfs patches and compatibility in the Lustre code is a non-trivial amount of work. RHEL5 itself is nearing the end of its support window (it is approaching 5 years old, the 2.6-rhel5.series file was added to Lustre in August 2007). The customers that are still running RHEL5 instead of upgrading to RHEL6 are very unlikely to be upgrading from Lustre 1.8 to Lustre 2.2 for exactly the same reasons (stability, lack of system testing resources, uptime requirements, etc). In addition to this ongoing maintenance effort, there is functionality missing from the RHEL5 kernel VM/VFS that is making ongoing work like the CLIO RPC restructuring (ORI-255, others) difficult or impossible to implement correctly. The client VFS dcache interface has changed significantly in Linux 2.6.38 and later, and the need for ongoing compatibility is making the llite code increasingly complex. Similarly, the ZFS code does not work on the RHEL5 kernel for the same "lack of API" reasons. Maintaining compatibility for the 2.6.18 kernel that is over 6 years old (released Sep 2006) keeps a lot of cruft and complexity in the client and server code (see lustre/autoconf/lustre-core.m4 for all of the kernel API changes we need to handle). The kernel developers make no effort to keep the APIs stable, and the more kernel versions we have to support the more complex our code has to become to compensate. This bug depends on TT-268 and TT-246 in order to disable RHEL5 server build and autotest before it can be landed. We may want to do this on the orion branch first (TT-242) in order to avoid causing problems with master. |
| Comments |
| Comment by Joshua Kugler (Inactive) [ 16/Jan/12 ] |
|
Do you mean RHEL 4? or RHEL 5? RHEL 4 is going to EOL in about a month or so here. RHEL 5 is supported through March 31, 2014, and has extended support through March 31, 2017. See: https://access.redhat.com/support/policy/updates/errata/ |
| Comment by Andreas Dilger [ 17/Jan/12 ] |
|
I mean RHEL5. According to the URL you posted (which I've visited previously) RHEL5 will be out of "Production 1" support when Lustre 2.2 is released (Q1 2012), which means that support for new hardware is only at the discretion of Red Hat. Within 9 months it will be out of "Production 2" (Q4 2012). That means no more service packs will be available, and no more new hardware support. Since Lustre 2.2 is not a "Maintenance Release", but rather a "Feature Release" (see http://wiki.whamcloud.com/display/PUB/Community+Lustre+Roadmap), it is targeted more at leading edge installations that need scalability and new functionality (and new hardware) in preference to long-term stable maintenance releases. The Lustre 2.1 release is being moved into "Maintenance Release" mode with a 2.1.1 update, and it still supports RHEL5. It is very unlikely that 2.2 will become a maintenance release, and instead the next maintenance release will be based on Lustre 2.3 or 2.4 a year or more from now. Since new customers will not be installing a new 5-year stable system based on RHEL5 and Lustre 2.2, the overhead of maintaining the support for that kernel in this code base can be eliminated and instead the effort be put towards cleaning out old kernel compatibility cruft in Lustre and updating it to support newer kernels and their ever changing APIs that will form the basis of a future vendor kernel. |
| Comment by Joshua Kugler (Inactive) [ 17/Jan/12 ] |
|
Thank you for the clarification. I was not versed on Redhat's various terms (Production 1, etc.). All I knew was "supported" and "EOL." |
| Comment by Peter Jones [ 08/Jan/13 ] |
|
Landed for 2.4 |