If anyone here is interested in co-mentoring or wants to help guide a student on these projects, I'd love to chat. Drop me a private message if you're interested!
I have read a bit on its web site, did not find my answer, but I am not an user of OpenWISP and this could be a stupid question: if OpenWISP already have records of all the managed devices, wouldn't it be easier to read /etc/os-release (or some other authoritative source for that info) from the devices themselves, then download the correct image? I mean, the celery job could do that, no humans required.
My OpenWRT real estate is minimal (no need for OpwnWISP yet ) - I have just bought an OpenWRT One to replace the previous router with less memory - and I have been using Ansible to configure the routers. I have also using it to perform the router upgrade and part of the work there is exactly that: determining the architecture and downloading the correct file. To be fair, I had to manually change the file extension from .bin used in the TPLink to .itb used in the One, but that is a to-do for me to accept different file extensions and pick the right one - that shouldn't be too difficult (I hope).
Is this for the use cases where OpenWISP is segregated from the internet? What is the use case for that feature? What am I missing?
OpenWISP already detects the hardware model and OpenWrt version from devices, hence it knows what type of firmware image it needs.
But firmware images, in most non trivial deployments, are usually customized, so users need to upload their own images. Right now the system cannot automatically extract metadata from uploaded images, users need to specify the hardware model during the upload phase, I want to solve this, if that project is successful users will be able to just upload images without having to specify the hardware model: it will be automatically detected.
Regarding automatic upgrades, it may work for networks with a low number of devices which are deployed in a single place. Things radically change for networks which have devices deployed in different cities or regions, sometimes in places that do not have easy access (roofs, towers, etc). Upgrades can fail, which means end users will have their service disrupted and replacement may take days, hence to avoid these kind of disruptions upgrades need to be planned beforehand, tested on a subset of devices and then executed for the rest of the network in a gradual fashion to ensure safe rollout. That’s what the Firmware Upgrader module of OpenWISP does.
Coming from a DevOps background, I would argue that what we are missing (it may already exist: I have not searched for that yet) is an easy and consistent mechanism to host images locally or within internal networks - just like we have pulp, artifact, nexus to provide rpm, apt, docker, python repositories. If we had that, the logic I mentioned would still work, only pointing to the internal repository rather than the official website. And of course it could/would have a cache-proxy feature, to make it faster internally and relieve some of the load from the official repo.
That would of course be a more elaborated avenue to explore and not necessarily associated with OpenWISP, so I'll stop digressing here
) - I have just bought an OpenWRT One to replace the previous router with less memory - and I have been using Ansible to configure the routers. I have also using it to perform the router upgrade and part of the work there is exactly that: determining the architecture and downloading the correct file. To be fair, I had to manually change the file extension from 
