SOLR-13696 Simplify routed alias tests to avoid flakiness, improve debugging

[gus-asf]

No description provided.

[gus-asf]

@tflobbe Please review what I did to make enable the uploading of config sets within tests possible. When I tried to re-enable this test it was failing it was untrusted and no auth (changes for https://issues.apache.org/jira/browse/SOLR-14663 ) ... certainly open to other suggestions, but it didn't seem reasonable to be trying to set up authentication just for a test.

[tflobbe]

Thanks for the ping @gus-asf. I’m on vacations without my computer. I can get back to this PR later this week If it’s still around.

[gus-asf]

@tflobbe later this week is fine :)

[tflobbe]

I don't think this will work well. Gradle runs multiple tests on the same JVM, static state will span multiple tests (so, depending on the order of tests, this could conflict with TestConfigSetsAPI or other classes testing auth or causing other inconsistencies).

How about replacing this code in RoutedAliasUpdateProcessorTest:

assertEquals(0, new ConfigSetAdminRequest.Create()
        .setConfigSetName(configName)
        .setBaseConfigSetName("_default")
        .process(getSolrClient()).getStatus());

With something like:

new ZkConfigManager(cluster.getZkClient()).copyConfigDir("_default", configName);

Would that work for you? You wouldn't be using the Configsets API, but I think that's OK, it's not what this class is trying to test?

[madrob]

it didn't seem reasonable to be trying to set up authentication just for a test.

I think this would be the correct approach. Are there other tests you can borrow authentication configs from?

[gus-asf]

Yeah sorry haven't got back to this. Work is quite busy. my recollection is that my initial thought was that the concern raised is not actually a problem since no tests run concurrently on the same vm, but.... I had not been going to say that until I spent some time verifying that...