Discovering Prosys OPC UA simulation server passes in DNS instead of IP address, making the server not discoverable

[yujinkim-msft]

Describe the bug
A clear and concise description of what the bug is.

Running a k3s cluster on AKS Edge Essentials with flannel as the CNI and a simulation OPC UA server from Prosys.
When deployed using the standard opc.tcp://<IP address>:<port>/ for the discoveryURL, upon inspecting the logs of the monitoring pod, it seems that Akri tries to pass in the DNS `opc.tcp://OPCTest: instead of the IP address as expected.

Output of kubectl get pods,akrii,akric -o wide
All pods are running as it should, there are no akri instances showing up.

Kubernetes Version: [e.g. Native Kubernetes 1.19, MicroK8s 1.19, Minikube 1.19, K3s]

To Reproduce
Steps to reproduce the behavior:

1. Create cluster using AKS Edge Essentials.
2. Run Prosys OPC UA simulation server
3. Install Akri with appropriate discoveryURL, identifier, and namespace index
4. Inspect discovery and monitoring pods as well as akrii.

Expected behavior
The Prosys OPC UA simulation server is discovered and show up when we run kubectl get akrii

Possible solution
I think this TODO item (line 138) in the code is the change we need to make to fix this.

[harrison-tin]

I'm interested in taking this! But have some questions on the design:

My understanding is that we are using the discoveryURL from the opc server, which in this case the server passes opc.tcp://OPCtest:53530/OPCUA/SimulationServer to the akri opcua discovery handler. However, when akri passes this discoveryUrl to the opc broker, it cannot resolve the url (because it doesn't have the same dns as the opc server?)

In the function get_discovery_url_from_application_description, we are only getting the url if it is ApplicationType::Server. So is there a reason we are getting the discoveryUrl from the server instead of using the ip address specified by the user? I'm not quite sure how we can translate the DNS to IP address on the discovery handler side, or request specifically for ip address.

[kate-goldenring]

I'd recommend reading the OPC UA specification -- likely the discovery one: https://opcfoundation.org/developer-tools/documents/view/169. You will need to create a free member account to read the public documents

[mregen]

Many servers do not return the discoveryUrl based on the Url used by a client to call GetEndpoints. (Not according to spec but thats reality).
Some SDK, e.g. the OPCF C# client, patch the returned endpoints or discoveryUrl with the hostname or IP used to connect to the discovery endpoint, to make it transparent for a user. Even worse, servers running in a docker container may have mapped their port to something different than the inside server port, then the discovery Url ports may also not match.

[harrison-tin]

Some SDK, e.g. the OPCF C# client, patch the returned endpoints or discoveryUrl with the hostname or IP used to connect to the discovery endpoint, to make it transparent for a user.

@mregen thanks for the details! So in the example of Prosys OPC UA server, let's say we found a server in opc.tcp://1.2.3.4:50000 to the server, and it returns opc.tcp://OPCTest:50000/endpoint to the client. OPCF C# client will patch both opc.tcp://1.2.3.4:50000 and opc.tcp://OPCTest:50000/endpoint (for transparency) to connect to the discovery endpoint, right?

in this PR, changes are made to Akri so that it will log both opc.tcp://1.2.3.4:50000 and opc.tcp://OPCTest:50000/endpoint and use opc.tcp://1.2.3.4:50000/endpoint to connect to the endpoint. Hope it makes sense and if you have any advice/feedback, it would be great!