Please add the ability to specify the two ports that are opened for event subscriptions in Device Servers
SKAO deploys a good part of the pyTango Device Servers in a Kubernetes cluster.
We have encountered a problem when a Device, that runs outside of the cluster, attempts to subscribe to events of a Device that runs on a Device Server in the cluster: The subscriptions simply do not work, events are never received.
The reason for this is simple: The DS allocates two sockets and asks 0MQ to bind those to ports. Tango does not specify the port numbers that 0MQ should bind the sockets to, so 0MQ binds them to ports with randomly chosen numbers.
Two scenarios where the missing feature hinders us at the moment:
- Kubernetes cannot expose these communication channels without us knowing the associated fixed port numbers in advance in order to be able to construct the necessary Kubernetes Service LoadBalancer resources.
- The same situation arises with our geographically distributed private networks. We operate one in Australia, one in South Africa and one in the United Kingdom. This configuration poses the same problem where ports, that need to be forwarded between networks, need to be known in advance.
Solution proposal It is already possible to specify the hostname/ip address and port number for the ORB endpoint, i.e. the underlying CORBA system. Here one can specify a host name or an IP address and a port number and tell a container to open that specific port for incoming connections. If the same mechanism would be made available for the two 0MQ event ports, then running a DS in a container would become a transparent operation.
We kindly ask for a new feature that:
- Allows to specify two port numbers.
- 0MQ binds the two event sockets to these two port numbers.
- Make this new configuration available through
- an environment variable as a first implementation and later, as an add-on through
- a command line parameter as well.
We have an internal proof of concept that demonstrates the viability of the proposed solution: piersharding/cppTango!2 (closed)
Not having this feature poses a non-negligible risk for development and deployment beyond our current planning (end of February 2022). We would therefore ask for this feature to be implemented until 2021-02-22. Due to the urgency, SKAO is prepared to help with the development, if the current Tango developer assignments cannot accommodate for such a short notice urgent feature request. Please send me a message and I am happy to set up a meeting.