Problem
A class of tests that could validate PostgREST behavior under adversarial network conditions requires a versatile tool enabling simulating them in tests.
Solution
Toxiproxi is one such tool. It is simple to use and is available in Nixpkgs.
Status
Several PRs were raised: #4674 and - based on review comments and request to split it - subsequent #4687 and #4688
It would be good to clarify the course of action as it seem there is some confusion and back-and-forth around it.
Issues to address
- We already have
slocat tool used to introduce latency and - while performing its task well - it does not provide the versatility we need (mainly: it cannot simulate other network conditions such as partitioning and it cannot be dynamically controlled from tests once started).
- Toxiproxy is a TCP only tool - it is not capable of proxying UNIX sockets.
@wolfgangwalther requested to replace slocat with toxiproxy as a first step only after which we would start writing tests leveraging toxiproxy capabilities.
That is only possible if either:
- we migrate our tests using
slocat right now from UNIX sockets to TCP sockets
- we replace
slocat with toxiproxy + socat (where socat is used to handle UNIX sockets and direct traffic to toxiproxy (ie. communication would be test <-UNIX socket-> socat <-TCP-> toxiproxy <-TCP-> socat <-UNIX socket-> postgrest)
After implementing the second option (ie. toxiproxy with socat), @steve-chavez requested removal of socat. This in turn requires switching mixed load tests to TCP, which was requested to be extracted to yet another PR.
The issue is that switching to TCP without removing slocat (or at least rewriting its usage and doing some non-trivial refactoring) is not really feasible (and wouldn't serve any actual purpose IMHO).
Let's decide on what steps we want to perform to achieve the goal of having a possibility to test postgrest with adversarial network conditions.
In my opinion the below options are most feasible:
- Introduce
toxiproxy, remove slocat and migrate load tests to TCP in one atomic PR.
- Introduce
toxiproxy without removing slocat in first step. Then remove slocat in the second step.
The third option suggested by @steve-chavez was to first remove slocat and only then introduce toxiproxy. But that would mean removing of existing APIs from withTools: withSlowPg and withSlowPgrst used by mixed load tests right now, only to re-introduce them in the future based on toxiproxy.
Problem
A class of tests that could validate PostgREST behavior under adversarial network conditions requires a versatile tool enabling simulating them in tests.
Solution
Toxiproxi is one such tool. It is simple to use and is available in Nixpkgs.
Status
Several PRs were raised: #4674 and - based on review comments and request to split it - subsequent #4687 and #4688
It would be good to clarify the course of action as it seem there is some confusion and back-and-forth around it.
Issues to address
slocattool used to introduce latency and - while performing its task well - it does not provide the versatility we need (mainly: it cannot simulate other network conditions such as partitioning and it cannot be dynamically controlled from tests once started).@wolfgangwalther requested to replace
slocatwithtoxiproxyas a first step only after which we would start writing tests leveragingtoxiproxycapabilities.That is only possible if either:
slocatright now from UNIX sockets to TCP socketsslocatwithtoxiproxy+socat(wheresocatis used to handle UNIX sockets and direct traffic totoxiproxy(ie. communication would betest<-UNIX socket->socat<-TCP->toxiproxy<-TCP->socat<-UNIX socket->postgrest)After implementing the second option (ie.
toxiproxywithsocat), @steve-chavez requested removal ofsocat. This in turn requires switching mixed load tests toTCP, which was requested to be extracted to yet another PR.The issue is that switching to
TCPwithout removingslocat(or at least rewriting its usage and doing some non-trivial refactoring) is not really feasible (and wouldn't serve any actual purpose IMHO).Let's decide on what steps we want to perform to achieve the goal of having a possibility to test postgrest with adversarial network conditions.
In my opinion the below options are most feasible:
toxiproxy, removeslocatand migrate load tests toTCPin one atomic PR.toxiproxywithout removingslocatin first step. Then removeslocatin the second step.The third option suggested by @steve-chavez was to first remove
slocatand only then introducetoxiproxy. But that would mean removing of existing APIs fromwithTools:withSlowPgandwithSlowPgrstused by mixed load tests right now, only to re-introduce them in the future based ontoxiproxy.