-
Notifications
You must be signed in to change notification settings - Fork 479
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Eliminate some raciness from gcpkms plugin tests (#5544)
* Eliminate some raciness from gcpkms plugin tests `TestDisposeActiveCryptoKeys` has a race condition where a goroutine that was processing keys for disposal was executing in parallel to some assertions on state of the same keys. Rework this test to address this race in the following ways: - Enhance the fake KMS client used in the test to consider the filter condition for the `spire-last-update` label passed in the `ListCryptoKeys()` request. The test was not considering this field before, even though it is one of the primary factors in the plugin determining how to handle the key. - Enrich the crypto keys set up in the fake KMS client by setting the `spire-last-update` label such that the plugin recognizes these keys as active based on last update time. - Assert that the keys are not scheduled for destruction. The destruction of the keys is handled asynchronously in the plugin. The current test could have passed if the keys were queued for destruction, but the other goroutine processing the destruction operations hadn't completed yet. This is a potential source of raciness in the test. - Make the mock clock used in the tests start at `time.Now()` instead of the Unix epoch because starting at the epoch causes some weird times to generated in the tests that are before the Unix epoch. Making these changes broke a couple other tests. Summary of changes to fix those tests: `TestDisposeStaleCryptoKeys`: - Start setting the `spire-last-update` label in the crypto keys set up in the fake KMS client so that the new filtering logic in `ListCryptoKeys()` in the fake KMS client gets exercised. - Set up an unbuffered `chan error` for the `keepActiveCryptoKeySignal` so that we can block the goroutine that is renewing the active key last update time. Without blocking this goroutine, it will keep renewing the last update time of the active keys, potentially before another parallel goroutine can process it as stale. - Advance the mock clock by the maximum of: - The duration that is the frequency of how often the stale key disposal goroutine runs - The maximum stale duration of a key The way the test is currently written assumes that the stale key disposal goroutine will run more frequently than the maximum stale duration, but it doesn't necessarily need to be the case. `TestKeepActiveCryptoKeys`: - Base the times in the test off of the current time rather than the Unix epoch as a start to align with other tests. Signed-off-by: Ryan Turner <[email protected]>
- Loading branch information
Showing
3 changed files
with
86 additions
and
22 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters