The disruptor consists of two main parts: a k6 extension and an agent that runs in the targets of the fault injection.
Presently, the separation of these two components is not evident in the code structure:
cmd
|-- agent // agent command
pkg
|-- agent // agent implementation
|-- api // extension api
|-- disruptors // extension implementation
|-- iptables // used by the agent
|-- kubernetes // used by the extension
|-- runtime // used by the agent
|-- testutils // used by agent and extension
|-- other packages (some may be shared)
This lack of clear separation brings some issues.
For example, the extension is expected to be multiplatform (as k6 itself is), while the agent in intended to run only in linux targets.
having to use build constrains to prevent some packages to build (or be tested) in non linux platforms can be tedious.
Therefore, It would be convenient to separate the code in at least four separate components:
agent
extension
shared (e.g utils, types)
test utils
An open question is whether these components should be independent modules in the same repository.
The disruptor consists of two main parts: a k6 extension and an agent that runs in the targets of the fault injection.
Presently, the separation of these two components is not evident in the code structure:
This lack of clear separation brings some issues. For example, the extension is expected to be multiplatform (as k6 itself is), while the agent in intended to run only in linux targets. having to use build constrains to prevent some packages to build (or be tested) in non linux platforms can be tedious.
Therefore, It would be convenient to separate the code in at least four separate components:
An open question is whether these components should be independent modules in the same repository.