Skip to content

Commit

Permalink
Added note about receptor not listening (ansible#2514)
Browse files Browse the repository at this point in the history
* Added not about receptor not listening

Explain in documentation that receptor is not listening on first controller

https://issues.redhat.com/browse/AAP-23036

* Added note about receptor not listening

Explain in documentation that receptor is not listening on first controller

https://issues.redhat.com/browse/AAP-23036
  • Loading branch information
ianf77 committed Nov 12, 2024
1 parent 22fe23f commit c40b30e
Show file tree
Hide file tree
Showing 2 changed files with 51 additions and 0 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -77,6 +77,30 @@ ALLOW connection from controller(s) to Receptor port |
====
* Hybrid nodes act as a combination of control and execution nodes, and therefore Hybrid nodes share the connections of both.
* If `receptor_listener_port` is defined, the machine also requires an available open port on which to establish inbound TCP connections, for example, 27199.
* It might be the case that some servers do not listen on receptor port (the default is 27199)
+
Suppose you have a Control plane with nodes A, B, C, D
+
The RPM installer creates a strongly connected peering between the control plane nodes with a least privileged approach and opens the tcp listener only on those nodes where it is required. All the receptor connections are bidirectional, so once the connection is created, the receptor can communicate in both directions.
+
The following is an example peering set up for three controller nodes:
+
Controller node A --> Controller node B
+
Controller node A --> Controller node C
+
Controller node B --> Controller node C
+
You can force the listener by setting
+
`receptor_listener=True`
+
However, a connection Controller B --> A is likely to be rejected as that connection already exists.
+
This means that nothing connects to Controller A as Controller A is creating the connections to the other nodes, and the following command does not return anything on Controller A:
+
`[root@controller1 ~]# ss -ntlp | grep 27199 [root@controller1 ~]#`
====

.{InsightsName}
Expand Down
27 changes: 27 additions & 0 deletions downstream/modules/platform/proc-define-mesh-node-types.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -153,6 +153,33 @@ Run the following command to open port 27199 for receptor communication:
----
sudo firewall-cmd --permanent --zone=public --add-port=27199/tcp
----
+
[NOTE]
====
It might be the case that some servers do not listen on receptor port (the default is 27199)
Suppose you have a Control plane with nodes A, B, C, D
The RPM installer creates a strongly connected peering between the control plane nodes with a least privileged approach and opens the tcp listener only on those nodes where it is required. All the receptor connections are bidirectional, so once the connection is created, the receptor can communicate in both directions.
The following is an example peering set up for three controller nodes:
Controller node A --> Controller node B
Controller node A --> Controller node C
Controller node B --> Controller node C
You can force the listener by setting
`receptor_listener=True`
However, a connection Controller B --> A is likely to be rejected as that connection already exists.
This means that nothing connects to Controller A as Controller A is creating the connections to the other nodes, and the following command does not return anything on Controller A:
`[root@controller1 ~]# ss -ntlp | grep 27199 [root@controller1 ~]#`
====
. Run the following playbook on the machine where you want to update your automation mesh:
+
Expand Down

0 comments on commit c40b30e

Please sign in to comment.