<div dir="auto">Fred,<div dir="auto">It may be that some HPC users "have to"</div><div dir="auto">reverify the results of their computations as being exactly the same as a previous software stack and that is not a minor task. Any change may require this verification process.....</div><div dir="auto">Ken Atkjnson</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 20 Feb 2020, 14:35 Frederick Stock, <<a href="mailto:stockf@us.ibm.com">stockf@us.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" style="font-family:Arial,Helvetica,sans-serif;font-size:12pt"><div dir="ltr">This is a bit off the point of this discussion but it seemed like an appropriate context for me to post this question.  IMHO the state of software is such that it is expected to change rather frequently, for example the OS on your laptop/tablet/smartphone and your web browser.  It is correct to say those devices are not running an HPC or enterprise environment but I mention them because I expect none of us would think of running those devices on software that is a version far from the latest available.  With that as background I am curious to understand why folks would continue to run systems on software like RHEL 6.x which is now two major releases(and many years) behind the current version of that product?  Is it simply the effort required to upgrade 100s/1000s of nodes and the disruption that causes, or are there other factors that make keeping current with OS releases problematic?  I do understand it is not just a matter of upgrading the OS but all the software, like Spectrum Scale, that runs atop that OS in your environment.  While they all do not remain in lock step I would  think that in some window of time, say 12-18 months after an OS release, all software in your environment would support a new/recent OS release that would technically permit the system to be upgraded.</div>
<div dir="ltr"> </div>
<div dir="ltr">I should add that I think you want to be on or near the latest release of any software with the presumption that newer versions should be an improvement over older versions, albeit with the usual caveats of new defects.</div>
<div dir="ltr"><div dir="ltr" style="font-family:Arial,Helvetica,sans-serif;font-size:10.5pt"><div dir="ltr"><br><font size="2" face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif"><span style="font-size:1.143em">Fred<br>__________________________________________________<br>Fred Stock | IBM Pittsburgh Lab | 720-430-8821<br><a href="mailto:stockf@us.ibm.com" target="_blank" rel="noreferrer">stockf@us.ibm.com</a></span></font></div></div></div>
<div dir="ltr"> </div>
<div dir="ltr"> </div>
<blockquote dir="ltr" style="border-left:solid #aaaaaa 2px;margin-left:5px;padding-left:5px;direction:ltr;margin-right:0px">----- Original message -----<br>From: Jonathan Buzzard <<a href="mailto:jonathan.buzzard@strath.ac.uk" target="_blank" rel="noreferrer">jonathan.buzzard@strath.ac.uk</a>><br>Sent by: <a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank" rel="noreferrer">gpfsug-discuss-bounces@spectrumscale.org</a><br>To: "<a href="mailto:gpfsug-discuss@spectrumscale.org" target="_blank" rel="noreferrer">gpfsug-discuss@spectrumscale.org</a>" <<a href="mailto:gpfsug-discuss@spectrumscale.org" target="_blank" rel="noreferrer">gpfsug-discuss@spectrumscale.org</a>><br>Cc:<br>Subject: [EXTERNAL] Re: [gpfsug-discuss] GPFS 5 and supported rhel OS<br>Date: Thu, Feb 20, 2020 6:24 AM<br> 
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace">On 20/02/2020 10:41, Simon Thompson wrote:<br>> Well, if you were buying some form of extended Life Support for<br>> Scale, then you might also be expecting to buy extended life for<br>> RedHat. RHEL6 has extended life support until June 2024. Sure its an<br>> add on subscription cost, but some people might be prepared to do<br>> that over OS upgrades.<br><br>I would recommend anyone going down that to route to take a *very* close<br>look at what you get for the extended support. Not all of the OS is<br>supported, with large chunks being moved to unsupported even if you pay<br>for the extended support.<br><br>Consequently extended support is not suitable for HPC usage in my view,<br>so start planning the upgrade now. It's not like you haven't had 10<br>years notice.<br><br>If your GPFS is just a storage thing serving out on protocol nodes,<br>upgrade one node at a time to RHEL7 and then repeat upgrading to GPFS 5.<br>It's a relatively easy invisible to the users upgrade.<br><br>JAB.<br><br>--<br>Jonathan A. Buzzard                         Tel: +44141-5483420<br>HPC System Administrator, ARCHIE-WeSt.<br>University of Strathclyde, John Anderson Building, Glasgow. G4 0NG<br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at <a href="http://spectrumscale.org" target="_blank" rel="noreferrer">spectrumscale.org</a><br><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank" rel="noreferrer">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a> </font><br> </div></blockquote>
<div dir="ltr"> </div></div><br>

_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
</blockquote></div>