Libnvds_azure_edge_proto connection methodology

Our deepstream-derived applications will be deployed as an Azure IoT Edge module (container). I am evaluating the nvmsgbroker and nvmsgconv gst plugins as the means by which our applications can communicate back to our web portal via Azure IoT. I’m reading the details in the section entitled " Connection Details for the Module Client Adapter" at this link: Gst-nvmsgbroker — DeepStream 6.1.1 Release documentation

If the documentation matches the implementation then I am concerned about how libnvds_azure_edge_proto has been implemented. Specifically, this looks incorrect:

“Leave the connection string empty, since the Azure IoT Edge library automatically fetches the connection string from the file /etc/iotedge/config.yaml .”

If your application is running as an Edge module (container) then you will not have access to this file. Furthermore, it wouldn’t work if you were using the Device Provisioning Service vs pre-provisioned devices with connection strings. In either scenario the protocol adapter should have received it’s connection via this call:

IoTHubModuleClient_CreateFromEnvironment()

Since this source seems to not be published (someone else has already posted about that - no reason this should be made public) then I’m unable to confirm the implementation. Please advise. As an alternative I could simply write my own gst message broker, but I wanted to give NVIDIA’s intended implementation due consideration.

Our deepstream-derived applications will be deployed as an Azure IoT Edge module (container). I am evaluating the nvmsgbroker and nvmsgconv gst plugins as the means by which our applications can communicate back to our web portal via Azure IoT. I’m reading the details in the section entitled " Connection Details for the Module Client Adapter" at this link: Gst-nvmsgbroker — DeepStream 5.1 Release documentation

If the documentation matches the implementation then I am concerned about how libnvds_azure_edge_proto has been implemented. Specifically, this looks incorrect:

“Leave the connection string empty, since the Azure IoT Edge library automatically fetches the connection string from the file /etc/iotedge/config.yaml .”

If your application is running as an Edge module (container) then you will not have access to this file.

→ Yes, iotedge take the connection string from /etc/iotedge/config.yaml, but how you deploy your module if you can not access the device which have your app running.

Furthermore, it wouldn’t work if you were using the Device Provisioning Service vs pre-provisioned devices with connection strings. In either scenario the protocol adapter should have received it’s connection via this call:

IoTHubModuleClient_CreateFromEnvironment()

→ device client and module client called different API to setup connection handle, the API you mentioned is just for module client.

Since this source seems to not be published (someone else has already posted about that - no reason this should be made public) then I’m unable to confirm the implementation. Please advise. As an alternative I could simply write my own gst message broker, but I wanted to give NVIDIA’s intended implementation due consideration.

→ You can use the DeepStream messaging interface, nvds_msgapi , to implement a custom protocol message handler and integrate it with DeepStream applications.
[/quote]

please let me know if any more questions.

The module is deployed via Azure IoT Edge’s infrastructure. An application creates a deployment manifest and uses the Azure IoT service SDK to deploy the manifest. The manifest contains what modules (containers) are to be deployed. Here is a nodejs example of that:

https://github.com/Azure/azure-iot-sdk-node/blob/master/service/samples/javascript/edge_deployment_sample.js

Once the module is deployed it will not have access to /etc/iotedge/config.yaml since it resides in the host system.

I’m guessing from your response that the implementation is correct since you indicated that IoTHubModuleClient_CreateFromEnvironment() is only used in the module client (which is our use case). I am trying to confirm by running the /opt/nvidia/deepstream/deepstream/sources/libs/azure_protocol_adaptor/module_client example. If that is the case then it is just the documentation that is incorrect.

“Leave the connection string empty, since the Azure IoT Edge library automatically fetches the connection string from the file /etc/iotedge/config.yaml .”
I do not get your points, did you mean above not correct?

Yes. Specifically, this part is incorrect:

"… since the Azure IoT Edge library automatically fetches the connection string from the file /etc/iotedge/config.yaml .”

An edge module client should use IoTHubModuleClient_CreateFromEnvironment() to obtain a client connection. The SDK abstracts how this client connection is obtained, but I believe that the connection is just a proxy for communication to the edgeHub module which funnels all module communication via a single connection instance to the Azure IoT Hub. For good measure I renamed /etc/iotedge/config.yaml to something else and ran the deepstream module_client example which worked proving that config.yaml is not used to fetch the connection string.

No, it’s right. it will get the connection string from environment variables. as stated by the documentation
"… since the Azure IoT Edge library automatically fetches the connection string from the file /etc/iotedge/config.yaml .”

If that were true then I should be able to find the code that does this in the SDK, correct?

There is no such code.