Hi Taylor,

When working in container mode, each container has a dedicated Edge function. Master container will run as the master. Worker containers can run as Job engine container or translation engine container.

When the container is started, the host agent will broadcast its capabilities (job/translation, LP).

The API gateway is continuously listening to the broadcast and is building the list of hosts dynamically.

In the log above, it seems that the API gateway has received the broadcast from a container started as a job engine (on 192.168.90.245).

Was the SDL_ETS_CONTAINER_HOST_AGENT properly set in the docker-compose.yml file to ensure the URL will be known to the master host running API gateway.

An example of the docker-compose.yml file can be found at https://docs.sdl.com/LiveContent/web/pub.xql?action=home&pub=SDL%20Machine%20Translation%20Edge%20Documentation-v7&lang=en-US#docid=GUID-41DCCDA1-077E-43B3-A909-11BD8D165010&addHistory=true&query=&scope=&tid=&filename=GUID-54ADA779-9494-46D7-927B-F49B30B429A0.xml&resource=&inner_id=&toc=false&eventType=lcContent.loadDocGUID-41DCCDA1-077E-43B3-A909-11BD8D165010

and is also available in the MT Edge installer root folder in /docker/

We aren't setting static hostnames for containers as our kubernetes infrastructure is fairly ephemeral. We have currently configured the host agent URLS to be set to the pod IP dynamically when it is started. Would this error be produced if the port 4637 wasn't open on the job engine container?

{name: SDL_ETS_CONTAINER_HOST_AGENT_URL, value: "http://$(POD_IP):4637" }

Hi Taylor,

I see. And yes, it could be related to the port 4637 not being available on the worker host. 

Regarding ports, the following must be configured:

- Port 4637 must be opened on all worker hosts to receive incoming requests from the API Gateway

- Port 5672 must be opened on the master host to receive incoming worker connections to the message broker.

Thanks

Thank you. It was indeed a networking policy issue on the backend. However, I had to open 5673 on the API gateway for it to work even though we are explicitly setting the port in the main-config.json to 5672 for amqp and 5671 for secure amqp. It seems like the latest versions (8.4.4+) of the MTE API binary is hard coding that expected port and ignoring what's in the configuration file. Is this intended? The change notes mentioned you made this change because it was conflicting with other rabbitmq installations.

Thank you. It was indeed a networking policy issue on the backend. However, I had to open 5673 on the API gateway for it to work even though we are explicitly setting the port in the main-config.json to 5672 for amqp and 5671 for secure amqp. It seems like the latest versions (8.4.4+) of the MTE API binary is hard coding that expected port and ignoring what's in the configuration file. Is this intended? The change notes mentioned you made this change because it was conflicting with other rabbitmq installations.

Hi Talyor.

In MT Edge 8.4.4+, we indeed changed the default ports used by the Message broker. The default are now 5674 and 5673 (instead of 5672 and 5671 respectively).

The etsbootstrap.py script needs to be updated accordingly, to ensure that the job and translation engines will use the appropriate ports.

Changes to be performed:

On line 107-108 and 120-121, change:

• 'port': 5672,
• 'securePort': 5671,

to

• 'port': 5674,
• 'securePort': 5673,

We are updated the MT Edge 8.4.5 installer package to include a modified version of the bootstrap script, but feel free to modify your own version of the script to match the new ports.

Thanks for reporting this.