Submitting request for Device Update for IoT Hub autoconnecting to Microsoft Delivery optimization interfaces

store-requests
#1

Hi @review-team ,

I am submitting request to auto-connect Azure Device update for IoT Hub snap to Microsoft Delivery Optimization snap per the instructions.

Device update for IoT Hub allows users to manage and update IoT devices (Documentation). Delivery Optimization is a dependency for Device Update to download update files.

Autoconnection for the below interfaces:

  1. do-config: DU to write configurations for the DO SDK.

  2. do-port-numbers: For DU to communicate with DO and instruct DO to download the update payloads

Thanks, Esha S

#2

(Adding other info in a second post due to new user limitations)

Device Update Snap Project: iot-hub-device-update/snap at feature/snap · Azure/iot-hub-device-update · GitHub

Device Update snap YAML: iot-hub-device-update/snap/snapcraft.yaml at feature/snap · Azure/iot-hub-device-update · GitHub

Delivery Optimization YAML: do-client/snapcraft-options/snapcraft-agent.yaml at develop · microsoft/do-client · GitHub DO Snap: Install deliveryoptimization-agent on Linux | Snap Store (snapcraft.io)

#3

I notice both of these snaps seem to be published under their own separate publisher accounts (with the same names as each of the snaps) - however, if they were published under the same account then the content interfaces would auto-connect automatically, without any need for this request - would it be possible to publish them both under the same account?

#4

@alexmurray As these have different scope and are managed by different teams, our preference is to have these be separate accounts for maintenance.

#5

@eshashah-msft is deviceupdate-agent meant to be published in the global store? I ask since the snapd-control interface is primarily intended to be used by brand store owners instead.

Submitting request for Device Update for IoT Hub to autoconnect to snapd- control
#6

Hi @alexmurray, I can also confirm that the single publisher account option was discussed and fully detailed with Microsoft by the Canonical Field team including this benefit during development. The decision for the multiple accounts being taken on the basis of their internal operational requirements.

2 Likes
#7

+1 from me for auto-connect the requested content interfaces as explained. Can other @reviewers please vote?

1 Like
#8

Thanks for the updated information regarding the choice of using multiple publishing accounts - +1 from me too for auto-connect of the requested content interfaces between these two snaps.

#9

Hello @eshashah-msft,

I will be able to grant this connection once a revision of the deviceupdate-agent snap is submitted to the store. Once this happens, the snap will be assigned a ID that we use in specifying the rules for auto-connecting to it.

#10

Thanks @dclane. We will publish a revised snap ASAP.

#11

hey @eshashah-msft, let us know once you’re done with publishing the revised snap

thanks

#12

Hi @0xnishit, we had published our snap. It was rejected due to autoconnect to snapd interface. I have started the human review process for the same: Manage version 0.1 of “deviceupdate-agent” (snapcraft.io) Please let me know if anything is needed from our end.

#13

I just saw this arrive in the store but noticed it failed automated review with an additional issue:


found errors in file output: unusual mode 'r-sr-xr-x' for entry './usr/lib/adu/adu-shell' security-snap-v2_squashfs_files

ie. it is shipping a setuid-root binary - these are generally not allowed since they could present a security issue - is this required? Could it be removed from the snap?

#14

@alexmurray: Yes. We will remove and update the snap.

#15

@eshashah-msft hey,

I can see the latest revision has some further issues, we left you some comments there. Let us know if you need further assistance.

Thanks!

#16

Hey @eshashah-msft , it’s been a while since the last activity on this thread. Let us know if you need help with this. Thanks

#17

Hey @eshashah-msft , since we’ve not heard back from you, we are removing this request from our review queue. When you have more time to respond, simply do so here and we can add the request back to the queue. Thanks.

#18

Hi @sahnaseredini, we have addressed the errors from the automated review and published the snap here. Can the delivery optimization interfac connect be enabled now?

#19

2 votes for, 0 against. Granting auto-connect to do-port-numbers and do-configs, (content interfaces from deliveryoptimization-agent). This is now live

Thanks.

2 Likes
#20

Hi @review-team,

In addition to the above interfaces, I would like to request autoconnect to deviceupdate-agent-downloads plug interface in the Device Update snap This enables download and storing update payloads by the Delivery Optimization Snap.

New autoconnect request for Device Update for IoT Hub