You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Presently, fault injection capabilitites are defined in a series of interfaces that defines a method for each type of fault.
For example, the ProtocolFaultInjector defines the methods for injecting HTTP and gRPC faults.
Each disruptor (PodDisruptor, ServiceDistruptor) has to implement these methods.
The implementation of each fault injection method for each disruptor is quite similar, differing mostly in the type of fault to be injected. To inject a fault the disruptor needs to translate this fault to a command to be sent to the agent in the target using an agent controller.
Complexity of tests: presently to validate how a fault is mapped to the corresponding agent commands it is necessary to instantiate the disruptors. This requires considerable setup and also creates the necessity to duplicate the tests for each disruptor
No clear separation of concerns
All the above seems to point to the need to reconsider the abstractions used for fault injection. In particular to decouple the fault injection from the disruptor to allow reuse across disruptors.
One initial analysis points to the idea of separating the fault injection logic into a component that has the sole responsibility of mapping faults to commands for a given target, validating that this mapping is possible/allowed.
The text was updated successfully, but these errors were encountered:
Presently, fault injection capabilitites are defined in a series of interfaces that defines a method for each type of fault.
For example, the
ProtocolFaultInjector
defines the methods for injecting HTTP and gRPC faults.Each disruptor (PodDisruptor, ServiceDistruptor) has to implement these methods.
The implementation of each fault injection method for each disruptor is quite similar, differing mostly in the type of fault to be injected. To inject a fault the disruptor needs to translate this fault to a command to be sent to the agent in the target using an agent controller.
This situation creates a series of issues:
All the above seems to point to the need to reconsider the abstractions used for fault injection. In particular to decouple the fault injection from the disruptor to allow reuse across disruptors.
One initial analysis points to the idea of separating the fault injection logic into a component that has the sole responsibility of mapping faults to commands for a given target, validating that this mapping is possible/allowed.
The text was updated successfully, but these errors were encountered: