1403691 - Change first NSS test cycle to explicitly use dbm file format

Status: RESOLVED FIXED

(NSS :: Test, enhancement, P1)

Description

[Kai Engert [:KaiE:]]

Currently, the dbm storage format is the default of NSS.

When the NSS test suite is executed, it runs 4 cycles.

I believe the first cycle implicitly depends on the dbm database format. We should fix it to explicitly request the dbm format.

This approach will probably ensure that the cycle named "upgradedb" also operates on the expected dbm input.

The cycle named "sharedb" probably already explicitly requests the sql format.

For the pkix cycle, not sure what we should do, I guess it doesn't matter much which format is used. Probably changing it to use sql, too, would be a good idea, but it could continue to rely on the default format.

Comment 1

[Kai Engert [:KaiE:]]

Hmm, I see the sharedb cycle limits the amount of tests executed. Was that done to avoid redundancy?

I think ideally the full set of tests should be executed with the sql format, and potential redundancy removals should be done for dbm.

Comment 2

[Kai Engert [:KaiE:]]

Attachment: dbmtest.patch

First attempt, does this patch seem reasonable? I've moved the limitations between standard (name for dbm) and sharedb (name for sql). I'm currently running local tests to check if we still get the same amount of tests. Feedback welcome.

Comment 3

[Robert Relyea]

RE comment 1. I think it was to limit the exponential explosion of tests. Tests that weren't all necessarily database based would have some version run as dbm and some version run as sql.

There are even a smaller set for updatedb, but many of the updatedb tests that were dropped were database creation tests, which didn't apply to databases that had all the certs and keys already created and updated from dbm.

Comment 4

[Robert Relyea]

re comment 2: That looks good. The only thing I'd do is skip upgradedb from sql and run it on the dbm side. upgradedb up grades a dbm database to an sql database. It would be a noop in the sql.

Comment 5

[Kai Engert [:KaiE:]]

Attachment: 1403691-v2.patch

(In reply to Robert Relyea from comment #4)
> re comment 2: That looks good. The only thing I'd do is skip upgradedb from
> sql and run it on the dbm side. upgradedb up grades a dbm database to an sql
> database. It would be a noop in the sql.

Thanks, this patch should implement your suggestion.

Comment 6

[Kai Engert [:KaiE:]]

(In reply to Kai Engert (:kaie:) from comment #2)
> I'm currently running local tests to check if we still get the same amount of tests.

I saw the same total number of tests executed in all scenarios (with and without patch, search for number of PASSED in output.log).

Comment 7

[Kai Engert [:KaiE:]]

I think we can land this at any time, even prior to landing bug 1377940, Franziskus, do you agree?

Comment 8

[Franziskus Kiefer [:franziskus]]

Sure, I don't see a reason to wait with landing this.

Comment 9

[Robert Relyea]

Comment on attachment 8913651 [details] [diff] [review]
1403691-v2.patch

Review of attachment 8913651 [details] [diff] [review]:
-----------------------------------------------------------------

r+ rrelyea

Comment 10

[Kai Engert [:KaiE:]]

https://hg.mozilla.org/projects/nss/rev/994e89150fc1cd0008d19a8ad8aafed565d98069

Comment 11

[Kai Engert [:KaiE:]]

This needs a follow-up fix.

Our pkits.sh test suite, which we run on buildbot, only (see bug 1375900), has been changed to be executed in the pkits.sh cycle.

The command to change the trust fails, because the database password is required, but not given.

Comment 12

[Kai Engert [:KaiE:]]

Attachment: 1403691-pkits-password.patch

Comment 13

[Robert Relyea]

Comment on attachment 8918320 [details] [diff] [review]
1403691-pkits-password.patch

Review of attachment 8918320 [details] [diff] [review]:
-----------------------------------------------------------------

r+ rrelyea

Comment 14

[Kai Engert [:KaiE:]]

https://hg.mozilla.org/projects/nss/rev/e73fedaecd63