https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-5037 Lustre <p>If one tries to change the release of MPSS that lbuild tries to build to 3.2.1 (for example) it fails to build with:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>+ '[' 3.2.1 = last ']' + [[ 3.2.1 != [0-9].[0-9].[0-9]*-[0-9]* ]] + fatal 1 'Incorrect MPSS version 3.2.1' + cleanup + true + error 'Incorrect MPSS version 3.2.1' + local 'msg=Incorrect MPSS version 3.2.1' + '[' -n 'Incorrect MPSS version 3.2.1' ']' + echo -e '\nlbuild: Incorrect MPSS version 3.2.1' lbuild: Incorrect MPSS version 3.2.1 </pre> </div></div> <p>This appears to be because there is an expectation that MPSS versions always end with a <tt>-$number</tt> but they don't. For example, current releases are:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>http://registrationcenter.intel.com/irc_nas/4030/mpss_gold_update_3-2.1.6720-23-rhel-6.0.tar http://registrationcenter.intel.com/irc_nas/4030/mpss_gold_update_3-2.1.6720-23-rhel-6.1.tar http://registrationcenter.intel.com/irc_nas/4030/mpss_gold_update_3-2.1.6720-23-rhel-6.2.tar http://registrationcenter.intel.com/irc_nas/4030/mpss_gold_update_3-2.1.6720-23-rhel-6.3.tar http://registrationcenter.intel.com/irc_nas/4030/mpss_gold_update_3-2.1.6720-23-rhel-6.4.tar http://registrationcenter.intel.com/irc_nas/4030/mpss_gold_update_3-2.1.6720-23-suse-11.1.tar http://registrationcenter.intel.com/irc_nas/4030/mpss_gold_update_3-2.1.6720-23-suse-11.2.tar http://registrationcenter.intel.com/irc_nas/4030/mpss_gold_update_3_src-2.1.6720-23_rhel.tar http://registrationcenter.intel.com/irc_nas/4030/mpss_gold_update_3_src-2.1.6720-23_suse.tar http://registrationcenter.intel.com/irc_nas/3988/mpss-3.1.4-rhel-6.0.tar http://registrationcenter.intel.com/irc_nas/3988/mpss-3.1.4-rhel-6.1.tar http://registrationcenter.intel.com/irc_nas/3988/mpss-3.1.4-rhel-6.2.tar http://registrationcenter.intel.com/irc_nas/3988/mpss-3.1.4-rhel-6.3.tar http://registrationcenter.intel.com/irc_nas/3988/mpss-3.1.4-rhel-6.4.tar http://registrationcenter.intel.com/irc_nas/3988/mpss-3.1.4-rhel-6.5.tar http://registrationcenter.intel.com/irc_nas/3988/mpss-3.1.4-suse-11.2.tar http://registrationcenter.intel.com/irc_nas/3988/mpss-3.1.4-suse-11.3.tar http://registrationcenter.intel.com/irc_nas/3988/mpss-src-3.1.4.tar http://registrationcenter.intel.com/irc_nas/3988/mpss-downloadcache-3.1.4.tar http://registrationcenter.intel.com/irc_nas/3988/mpss-3.1.4-k1om-gdb.tar http://registrationcenter.intel.com/irc_nas/4110/mpss-3.2.1-rhel-6.0.tar http://registrationcenter.intel.com/irc_nas/4110/mpss-3.2.1-rhel-6.1.tar http://registrationcenter.intel.com/irc_nas/4110/mpss-3.2.1-rhel-6.2.tar http://registrationcenter.intel.com/irc_nas/4110/mpss-3.2.1-rhel-6.3.tar http://registrationcenter.intel.com/irc_nas/4110/mpss-3.2.1-rhel-6.4.tar http://registrationcenter.intel.com/irc_nas/4110/mpss-3.2.1-rhel-6.5.tar http://registrationcenter.intel.com/irc_nas/4110/mpss-3.2.1-suse-11.2.tar http://registrationcenter.intel.com/irc_nas/4110/mpss-3.2.1-suse-11.3.tar http://registrationcenter.intel.com/irc_nas/4110/mpss-src-3.2.1.tar http://registrationcenter.intel.com/irc_nas/4110/mpss-3.2.1-k1om.tar http://registrationcenter.intel.com/irc_nas/4110/mpss-downloadcache-3.2.1.tar </pre> </div></div> <p>Fixing this is required to get us off of a private-not-available-publicly release to something which can be downloaded and built automatically by lbuild. Having to deal with non-public releases is very expensive in terms of manpower as it requires TEI to manually download and deploy these builds.</p> LU-5037

mpss 3.2.1 fails to build

Bug Major Resolved Fixed Dmitry Eremin Brian Murrell Fri, 9 May 2014 18:14:58 +0000 Thu, 8 Dec 2016 00:03:51 +0000 Mon, 8 Sep 2014 10:06:05 +0000 Lustre 2.7.0 0 3 <p>Dmitry</p> <p>Can you comment on this?</p> <p>Thanks</p> <p>Peter</p> <p>Actually the format of specifying MPSS version is not directly related to "private-not-available-publicly release". The number can be specified as zero and publicly available build will be used for build. Probably this behavior should be by default is number is not specified.</p> <blockquote> <p>The number can be specified as zero and publicly available build will be used for build</p></blockquote> <p><a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=dmiter" class="user-hover" rel="dmiter">dmiter</a>: Can you be more precise? Which number can be 0? The whole version number or some component of it?</p> <p>If you specify "<b>--mpss-version=3.2.1-0</b>" option for lbuild script it should download and build Lustre for MPSS 3.2.1.</p> <p>Ahhh! Yes, this seems to work. One of the pitfalls of "special meaning" bits is that their special meaning is often lost.</p> <p>Thanks for the info!</p> <p>There is a problem with the solution however:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> # force re-download if build number is zero [[ $MPSS_VERSION = [0-9].[0-9].[0-9]*-0 ]] &amp;&amp; force=true ... download_file "$url" "$file" "$force" </pre> </div></div> <p>So while adding the <tt>-0</tt> does make lbuild find the release, it has the side effect of causing a download to happen for each build even if the files already exist locally.</p> <p>This is particularly ugly in the case of MPSS given that the download is 1.3GB!</p> <p>It was done intentionally to avoid caching of old packages. If remove this line it will not be re-downloaded after new package become available on WEB page.</p> <p>As workaround I can propose just rename packages in cache with fake build number after first run and use this number in command line for subsequent runs of lbuild script.</p> <p>Yes, I understand that the <tt>-0</tt> is a special nomenclature to force re-download but that conflicts with the requirement to add a (fake) <tt>-0</tt> in order to pass the "is this a valid version" test that is in the code. The problem is that those are two different things but they are indicated using the same indicator so you can't have one without the other, but we need one without the other. We need to give a version that will pass the version check test (or change/fix the version check test) but not cause a re-download of 1.3GB of data for every build.</p> <blockquote> <p>As workaround I can propose just rename packages in cache with fake build number after first run and use this number in command line for subsequent runs of lbuild script.</p></blockquote> <p>This is an unacceptable solution since it means having to manually do this on every builder of which there are many. It doesn't scale.</p> <p>Now master will build with any version specification.</p> Development Rank 1|hzwm7j: Rank (Obsolete) 13928 Severity