[LU-6098] enable test-framework.sh:setupall() to start servers only

• Status: Resolved
• Project: Lustre
• Type: Improvement
• Priority: Trivial
• Reporter: Olaf Faaland
• Assignee: Jian Yu
• Resolution: Won't Fix
• Labels: patch

Description

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.

One change is to make it start only the servers, when an environment variable SERVERONLY is set.

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.

Combined, these make it easier to examine the startup process.

Comments

[Gerrit Updater]

Olaf Faaland-LLNL ([e-mail]) uploaded a new patch: http://review.whamcloud.com/13300
Subject: LU-6098 tests: skip client mount in test-framework
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 7b54b73fc20378a07c0e0b4fdd5dba4773c5bded

[Gerrit Updater]

Olaf Faaland-LLNL ([e-mail]) uploaded a new patch: http://review.whamcloud.com/13301
Subject: LU-6098 tests: start debug_daemon before server start
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 0c4bd2f636689da3ee6640f1fb6a638eb0644cf2

[Peter Jones]

Jian

Could you please review this patch?

Thanks

Peter

[Olaf Faaland]

I fixed the formatting issues and re-pushed the patch.

[Jian Yu]

Thank you Olaf for the patches. I'll review them.

[Olaf Faaland]

Jian,

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.

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?

-Olaf

[Jian Yu]

Hi Olaf,

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:

Test-Parameters: alwaysuploadlogs envdefinitions=START_DEBUG_DAEMON=true \
testlist=runtests

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.

[Olaf Faaland]

Hello Jian,

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.

I chose to stick with using

[ -n $DAEMONFILE ]

as the condition that causes debug_daemon to be started, so that the user has partial control over the filename.

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.

If you feel strongly about either of those, I'm open to changing them.

thanks,
Olaf

[Jian Yu]

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.

[Olaf Faaland]

Jian,

I rebased these patches and fixed the checkpatch complaints, but the patch timed out in sanity test 56a (LU-6133, I saw you were working on it).

Is there any way for me to proceed, or should I wait for LU-6133 to be resolved?

thanks,
Olaf

[Jian Yu]

Hi Olaf,

Is there any way for me to proceed, or should I wait for LU-6133 to be resolved?

Thank you for updating the patches. I just restarted the patch review testing.

[Olaf Faaland]

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.

However, thank you, Jian, for helping me out with them.

[Jian Yu]

You're welcome, Olaf. May I close this ticket?

[Olaf Faaland]

Yes, do close it.