Since we are going to abort 50% of the requests, having only one probe with a request might not produce the result that we want. Getting the desired would rely on luck since we couldn’t predict whether that request would fall into the 50% that are aborted. To reduce the possibility of randomness influencing our steady-state hypothesis, we are going to repeat that request four more times. However, instead of defining the whole probe, we have a shortcut definition. The second probe also has the tolerance 200, but it is referencing the probe app-responds-to-requests. So, instead of repeating everything, we are just referencing the existing probe, and we are doing that four times.

All in all, we are sending requests, and we’re expecting the 200 response code five times.

Then we have a method with the action abort-failure. It’s using the module chaosistio.fault.actions and the function add_abort_fault. It should be self-descriptive, and you should be able to guess that it will add abort faults into an Istio Virtual Service. We can also see that the action is targeting the Virtual Service go-demo-8.