Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
106768: base,server,testutils: clarify the multi-tenant test situations r=yuzefovich a=knz Informs cockroachdb#76378 . Informs cockroachdb#106772. Epic: CRDB-18499 Prior to this patch, a test could choose only between the following options: - `TestTenantProbabilisticOnly` and `TestTenantProbabilistic`: whether or not the load goes to a secondary tenant is randomly selected for each test. - `TestTenantEnabled`: always use a secondary tenant. - `TestTenantDisabled`: always disable the secondary tenant. In particular the last option was problematic, as we ended up using it both in the case "the test doesn't work with secondary tenants and *we don't know why*" and the case "it doesn't work, we know why *and it's OK to keep it that way*". We actually want to distinguish these cases, because the former case requires further investigation, and we want the test code to refer to this follow-up work more clearly. To address this, this commit defines the following options: ```go // (UNCHANGED) TestTenantProbabilisticOnly // (UNCHANGED) TestTenantProbabilistic // RENAMED: was previously "TestTenantEnabled" // // TestTenantAlwaysEnabled will always start the default test tenant. This is useful // for quickly verifying that a test works with tenants enabled. // // Note: this value should not be used for checked in test code // unless there is a good reason to do so. We want the common case // to use TestTenantProbabilistic or TestTenantProbabilisticOnly. TestTenantAlwaysEnabled // RENAMED: was previously "TestTenantDisabled" // // TODOTestTenantDisabled should not be used anymore. Use the // other values instead. // TODO(cockroachdb#76378): Review existing tests and use the proper value instead. TODOTestTenantDisabled = DefaultTestTenantOptions{testBehavior: ttDisabled} // (NEW) TestIsSpecificToStorageLayerAndNeedsASystemTenant is used when // the test needs to be given access to a SQL conn to a tenant with // sufficient capabilities to access all the storage layer. // (Initially that'd be "the" system tenant.) TestIsSpecificToStorageLayerAndNeedsASystemTenant // (NEW) TestControlsTenantsExplicitly is used when the test wants to // manage its own secondary tenants and tenant servers. TestControlsTenantsExplicitly // (NEW) TestNeedsTightIntegrationBetweenAPIsAndTestingKnobs is used when // a test wants to use a single set of testing knobs for both the // storage layer and the SQL layer and for simplicity of the test // code we want to give that test a simplified environment. // // Note: it is debatable whether the gain in test code simplicity is // worth the cost of never running that test with the virtualization // layer active. TestNeedsTightIntegrationBetweenAPIsAndTestingKnobs // (NEW) TestDoesNotWorkWithSecondaryTenantsButWeDontKnowWhyYet can be used // to disable virtualization because the test doesn't appear to be compatible // with it, and we don't understand it yet. // It should link to a github issue with label C-test-failure. TestDoesNotWorkWithSecondaryTenantsButWeDontKnowWhyYet(issueNumber int) // (NEW) TestIsForStuffThatShouldWorkWithSecondaryTenantsButDoesntYet can be // used to disable virtualization because the test exercises a feature // known not to work with virtualization enabled yet but we wish it // to work eventually. // // It should link to a github issue with label C-bug // and the issue should be linked to an epic under INI-213 or INI-214. TestIsForStuffThatShouldWorkWithSecondaryTenantsButDoesntYet(issueNumber int) ``` Release note: None Co-authored-by: Raphael 'kena' Poss <[email protected]>
- Loading branch information