[SOLR-13079] refactor and harden common 'suspend-trigger' patern in autoscaling test setup

• Type: Sub-task
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 7.7, 8.0
• Assignee: Chris M. Hostetter
• Reporter: Chris M. Hostetter
• Created: 18/Dec/18 04:03
• Updated: 11/Feb/19 09:20
• Resolved: 18/Dec/18 19:17

Description

A semi-common pattern in autoscaling tests is that immediately after configuring the cluster, they (ab)use AutoScalingHandlerTest.createAutoScalingRequest(...) to exec suspend-trigger on ".scheduled_maintenance".

The problem that can occasionally pops up in jenkins failures is that it's possible the OverseerThread hasn't gotten a chance to add this implicit trigger to the schedule by the time the test code tries to do this...

   [junit4] ERROR   0.03s J1 | TestSimTriggerIntegration.testCooldown <<<
   [junit4]    > Throwable #1: java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: org.apache.solr.api.ApiBag$ExceptionWithErrObject: Error in command payload, errors: [{suspend-trigger={name=.scheduled_maintenance}, errorMessages=[No trigger exists with name: .scheduled_maintenance]}], 
   [junit4]    >        at __randomizedtesting.SeedInfo.seed([51029DC2D3857924:60BCF026AD2F0CD6]:0)
   [junit4]    >        at org.apache.solr.cloud.autoscaling.sim.SimCloudManager.request(SimCloudManager.java:654)
   [junit4]    >        at org.apache.solr.cloud.autoscaling.sim.SimCloudManager$1.request(SimCloudManager.java:224)
   [junit4]    >        at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1260)
   [junit4]    >        at org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.setupTest(TestSimTriggerIntegration.java:136)

I think we should:

1. refactor the AutoScalingHandlerTest.AutoScalingRequest static inner class into CloudTestUtils
2. add a helper method to CloudTestUtils to make it easy to wait for a trigger to be scheduled
3. add a helper method to CloudTestUtils to make it easy to susspend an existing trigger