Currently, there are two methods in "Device management" to reference files used by devices to install software/firmware or configuration.
Upload a binary (which is then stored in Mongo DB)
Provide a file path
Option 1 has a file size limitation, so it can't be used in a number of cases. In particular, it cannot be used to store an Edge firmware update image as suggested here (https://cumulocity.com/guides/edge/remote-connectivity/#updating-edge-remotely), becuase the tgz Edge firmware file is too large.
Option 2 can be used to reference an arbitrary URL from which the device can download a file. But it has these limitaitons:
the device may not be able to access this URL, particularly if it is separated from the tenant by a firewall.
the file must be freely available at this URL, to download by anyone (i.e. without authentication)
there is no means to ensure that the location is not "spoofed", and thereby the device recieves a file which is not authentic.
We propose to extend Option 2 by allowing the file to be stored on the Cumulocity Tenant (whether in the Cloud, or on an Edge tenant) but not in MongoDB, and served via the same URL and through the same secure TLS link which the device uses to connect and transfer data.
Hi Niko,
I think mainly because of storage efficiency if the file is stored in MongoDB. Using that approach, it is subject to 3x replication, which can drive quite high costs, particularly if there are multiple large firmware images. I suppose that changing the Tenant so that it never used MongoDB to store firmware/software files, would make sense on that basis.
I'm not sure I clearly understand how a device retrieves a file which is uploaded using Option 1. For example, can it retrieve the file if its only connected via MQTT? Or perhaps it always uses a REST call, regardless of whether Option 1 or Option 2 is selected, in which case, from the device perspective, there is no practical difference between Option 1 and Option 2?
N
Hi Neil,
thanks a lot for the feedback. I was just wondering why you were not suggesting to extend option 1. (change the file size limit or way we are storing firmware images within a tenant).
We have already a very similar idea that I linked which is about providing a download proxy. Currently, this is an idea on our backlog but not scheduled for implementation especially as a download proxy brings a lot of challenges in large scale rollout scenarios.
Cheers,
Nikolaus