Nadia Santalla

> Can we define them (and their differences) easily? Can we use one or the other using an option in the fault? I think that with some documentation effort and...

A similar approach I've seen working in other projects is to use a ci-only image name/tag, that guarantees such image cannot be pulled. For example, something like `ci.local/grafana/xk6-disruptor`. Something like...

> then the problem mentioned in the issue would likely happen. You're right, I was thinking in CI scenarios where we can assume the image has not been built before....

@pablochacin It seems like https://github.com/grafana/xk6-disruptor/pull/376 updated grpc, which desyncs us from k6 core :(

This is a pity as personally I wouldn't find comfortable recommending port-forward in guides if it is this brittle. I'll try to reproduce this on my end just to see...

Some thoughts regarding two of the disadvantages: > There are security considerations regarding allowing the users running the tests to inject the agent into the pods. As mentioned before, they...

> having to define and apply polices to a cluster doesn't feels transparent My current understanding is that that's not the case. In the documentation they mention that a simple...

A possible API coming to my mind could be: ```js const fault = { errorCode: 500, errorRate: 0.1, errorBody: '{"this": "that"}', errorHeaders: {"This-Is": "A hardcoded header"}, passthroughHeaders: ["Trace-Id"] }; ```...

A big rock for retaining/passing through headers are non-GET requests. `GET` requests are strongly encouraged to be free of side-effects, but any other type is almost certainly not. To be...

Agreed, I think the static headers should cover potential use cases for `Content-Type` and so on. If a strong use case requiring dynamic headers rises, we can think what to...