[LU-729] Remove lustre-tar tests from sanity.

• Status: Resolved
• Project: Lustre
• Type: Task
• Priority: Minor
• Reporter: Richard Henwood (Inactive)
• Assignee: WC Triage
• Resolution: Won't Fix

Description

Lustre-tar test suite (sanity.sh) contains a number of tests (102 series) that test for a Lustre-enabled version of tar.

By including lustre-tar tests in sanity.sh, it means that lustre testing has a hard dependency on lustre-tar. This is not a desirable dependency: lustre-tar is not a prerequisite for running lustre.

102 series of lustre-tar tests should be extraction into a lustre-tar specific test suite and removal from sanity.sh

Comments

[Robert Read (Inactive)]

Alternatively they could just detect if lustre-tar is installed and SKIP if not.

[Chris Gearing (Inactive)]

Skipping is something to be avoided, I know we do it a lot but we should not add to the list.

If you run a test script then you should at the end simply be able to see if all the tests passed, automatic skipping means you know that some of the tests passed and none of the tests failed but not that all the tests passed.

If we want to remove the dependency of sanity from lustre-tar then do as Richard suggests and create a new test script called lustre-tar.sh or something else appropriate.

[Robert Read (Inactive)]

I agree in an ideal world all tests would be parameterized, and we would only run the tests that were applicable for a given situation. Until we have that kind of system, then skipping is the most expedient way to handle optional features.

[Richard Henwood (Inactive)]

tar has it's own test suite that is called during a typical build.

/lustre-tar/ has tests that require a lustre filesystem.

For these tests, there is a dependency.

Options include:

1. including in sanity.sh with SKIP if lustre-tar isn't present.

or alternatively:

2. lustre-tar has a dependency on lustre: lustre-tar.sh requires that lustre be installed.

[Andreas Dilger]

I'm not sure what the issue is here. The sanity.sh test_102[dfj] tests already check whether a lustre-aware tar is installed (currently by checking for the "lustre" string in the first "tar" binary in the path), and the tests are skipped otherwise. I don't see that we need to introduce another mechanism or script at this point, unless we are suddenly going to be adding a large number of subtest for tar.

[Nathan Rutman]

See LU-682 – can "Lustre tar" be deprecated in favor of RHEL6.3's tar 1.23-7?

[Andreas Dilger]

Upstream tar now has support for xattrs, and this is a non-issue.