Force localhost connections when client connects to localhost #305
Conversation
|
Requires some manual QA before merging. @Gsantomaggio @lukebakken could we introduce this in a patch release? Arguably it doesn't add new functionality, but a slight change in behaviour. |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #305 +/- ##
==========================================
- Coverage 92.86% 92.66% -0.20%
==========================================
Files 112 112
Lines 9742 9795 +53
Branches 774 786 +12
==========================================
+ Hits 9047 9077 +30
- Misses 532 546 +14
- Partials 163 172 +9
☔ View full report in Codecov by Sentry. |
I don't think we should mark the test to be skipped. In my commit, the test is marked "maybe skip", and it will always run, at least to the point where the Allow me to do manual QA for a couple hours before we consider merging. |
Related to #296 It is common to have a local instance of RabbitMQ running locally, either via a local rabbit (e.g. installed from source), or inside a container (e.g. Docker or local Kubernetes). In both cases, our client may not work without providing an address resolver, or without changing the advertised host/port in rabbit via an env variable. Specifically, our clients won't work if the client can't resolve the hostname of the local machine. For exampe, a laptop may have a hostname mylaptop.some-company.com. Rabbit won't be impacted as long as it works in a single-node configuration. However, the client smart features to locate the stream leaders and replicas will get "confused" because it can't resolve the hostname. This commit changes the smart layer, so that it won't try to locate the stream replicas if the client is connected to localhost. Instead, it will force the producer/consumer connections to be localhost, and it will assume that stream replicas/leader are in localhost. This is true for single-node rabbits in local development environments. The smart feature to locate leader/replicas remains unchanged for non-local connections. Signed-off-by: Aitor Perez Cedres <[email protected]>
Signed-off-by: Gabriele Santomaggio <[email protected]>
Zerpet
force-pushed
the
zerpet/localhost-issue
branch
from
8fa9566 to
049343f
Compare
|
Rebased branched on top of |
Fixes #296
It is common to have a local instance of RabbitMQ running locally,
either via a local rabbit (e.g. installed from source), or inside a
container (e.g. Docker or local Kubernetes). In both cases, our client
may not work without providing an address resolver, or without changing
the advertised host/port in rabbit via an env variable. Specifically,
our clients won't work if the client can't resolve the hostname of the
local machine.
For exampe, a laptop may have a hostname mylaptop.some-company.com.
Rabbit won't be impacted as long as it works in a single-node
configuration. However, the client smart features to locate the stream
leaders and replicas will get "confused" because it can't resolve the
hostname.
This commit changes the smart layer, so that it won't try to locate the
stream replicas if the client is connected to localhost. Instead, it
will force the producer/consumer connections to be localhost, and it
will assume that stream replicas/leader are in localhost. This is true
for single-node rabbits in local development environments. The smart
feature to locate leader/replicas remains unchanged for non-local
connections.