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-6098 Lustre <p>llmount.sh uses test-framework.sh:setupall() to start the MGS, MDT, OSTs, and then mount the client. setupall() can currently be made to only mount the client, by setting an environment variable CLIENTONLY. It starts the debug_daemon, if an environment variable DAEMONFILE is set.</p> <p>One change is to make it start only the servers, when an environment variable SERVERONLY is set. </p> <p>The second change is to start debug_daemon before starting servers, if DAEMONFILE is set, instead of starting it before mounting the client, as it does now.</p> <p>Combined, these make it easier to examine the startup process.</p> LU-6098

enable test-framework.sh:setupall() to start servers only

Improvement Trivial Resolved Won't Fix Jian Yu Olaf Faaland patch Thu, 8 Jan 2015 22:33:36 +0000 Tue, 25 Aug 2015 00:55:43 +0000 Tue, 25 Aug 2015 00:55:43 +0000 0 5 <p>Olaf Faaland-LLNL (ofaalandllnl@gmail.com) uploaded a new patch: <a href="http://review.whamcloud.com/13300" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/13300</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-6098" title="enable test-framework.sh:setupall() to start servers only" class="issue-link" data-issue-key="LU-6098"><del>LU-6098</del></a> tests: skip client mount in test-framework<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 7b54b73fc20378a07c0e0b4fdd5dba4773c5bded</p> <p>Olaf Faaland-LLNL (ofaalandllnl@gmail.com) uploaded a new patch: <a href="http://review.whamcloud.com/13301" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/13301</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-6098" title="enable test-framework.sh:setupall() to start servers only" class="issue-link" data-issue-key="LU-6098"><del>LU-6098</del></a> tests: start debug_daemon before server start<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 0c4bd2f636689da3ee6640f1fb6a638eb0644cf2</p> <p>Jian</p> <p>Could you please review this patch?</p> <p>Thanks</p> <p>Peter</p> <p>I fixed the formatting issues and re-pushed the patch.</p> <p>Thank you Olaf for the patches. I'll review them.</p> <p>Jian,</p> <p>Thank you for your comments. With regards to the two places where $LCTL should be run via do_nodes so that it is executed remotely when appropriate, I agree but have no existing environment in which to test the remote case. </p> <p>I can make the changes and test them in my environment (all components running on the same machine), and I believe it will work for the remote case. Do you, or someone, have an environment in which to test the remote case, easily?</p> <p>-Olaf</p> <p>Hi Olaf,</p> <p>Please feel free to update the patch after it passes your local testing. The autotest system will verify the patch on 4 test nodes (2 Clients + 1 MDS + 1 OSS). In order to test the case of starting debug daemon on remote nodes, you can add the following test parameters into the commit message:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Test-Parameters: alwaysuploadlogs envdefinitions=START_DEBUG_DAEMON=true \ testlist=runtests </pre> </div></div> <p>I saw setupall was used in lustre/tests/runtests. You can also specify other tests (sanity, conf-sanity, etc.) that use setupall to the above testlist.</p> <p>Hello Jian,</p> <p>Thank you. I submitted updated code without the Test-Parameters to allow autotest to verify the normal case (DAEMONFILE is null). When it looks to be done, I'll amend the commit message and submit again to kick off autotest with DAEMONFILE non-null.</p> <p>I chose to stick with using </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>[ -n $DAEMONFILE ] </pre> </div></div> <p> as the condition that causes debug_daemon to be started, so that the user has partial control over the filename.</p> <p>I chose to stick with -z for testing CLIENTONLY and SERVERONLY because I've seen that used widely in shell scripts, and so I think will be more predictable to new folk, and because it avoids the user being confused when they use some variant of true that I did not check for.</p> <p>If you feel strongly about either of those, I'm open to changing them.</p> <p>thanks,<br/> Olaf</p> <p>That's fine Olaf. For Test-Parameters, it's an extra custom test session that does not affect the normal review test sessions, so you can still specify the test parameters with non-null DAEMONFILE. The normal review test sessions will be run with null DAEMONFILE by default.</p> <p>Jian,</p> <p>I rebased these patches and fixed the checkpatch complaints, but the patch timed out in sanity test 56a (<a href="https://jira.whamcloud.com/browse/LU-6133" title="sanity test_56a: timeout" class="issue-link" data-issue-key="LU-6133"><del>LU-6133</del></a>, I saw you were working on it).</p> <p>Is there any way for me to proceed, or should I wait for <a href="https://jira.whamcloud.com/browse/LU-6133" title="sanity test_56a: timeout" class="issue-link" data-issue-key="LU-6133"><del>LU-6133</del></a> to be resolved?</p> <p>thanks,<br/> Olaf</p> <p>Hi Olaf,</p> <blockquote><p>Is there any way for me to proceed, or should I wait for <a href="https://jira.whamcloud.com/browse/LU-6133" title="sanity test_56a: timeout" class="issue-link" data-issue-key="LU-6133"><del>LU-6133</del></a> to be resolved?</p></blockquote> <p>Thank you for updating the patches. I just restarted the patch review testing.</p> <p>The use case I had in mind was local testing, and making these scripts more complex for that, now seems to me like a bad idea. I'm abandoning the two patches.</p> <p>However, thank you, Jian, for helping me out with them.</p> <p>You're welcome, Olaf. May I close this ticket?</p> <p>Yes, do close it.</p> Development Rank 1|hzx3if: Rank (Obsolete) 16974