this is the first status report before the initial evaluation. It will cover the current status and my plans for the next weeks. As planed, I manged to set up a demo instance of the update-server and a working version of the luci web-view. Both will be covered later in this article.
What has been done
The user interface received a new tab entry called “Attended Sysupgrade”. A click opens the very simple update view. Later additional information may be added.
The button fires an image request to the server based on retrieved system information (installed distribution, packages, version). The server returns status codes as described in the git repository.
created. The view will be updated accordingly.
Once the image is created a flash button appears, a click will download the created image from the server and uploads it to the router. Once done, a new created
ubus call will initiate a sysupgrade keeping all settings.
After a reboot the new release is installed (see bottom right).
Behind the scenes
To upload the image to the router, the package
cgi-io is used, saving the
The updates server is as well splittet in three parts. The request handling, a simple cli and the image building.
Currently a simple flask server provides the needed routing of
download. All requests will be checked for sanity and only then processed. If the request is valid a database lookup will check if the image was build before or is currently building. If none of these, a build job is added to the queue.
Whatever action is performed, the server tells the web interface the current status.
Currently the flask server will run in a gunicorn instance with any number of worker threads. Gunicorn runs behind a Nginx which handles the image download as well:
/download will only increase a counter and redirect to a
/static folder full of created images.
Command Line Interface
The CLI helps to setup the update server. It has commands to initially setup the database, fill it with data, setup Imagebuilders and update package lists. Right now the Imgebuilders initialization is automated but not jet on demand, only triggered by command line.
In a future release the CLI could also create images for testing, clean the update server and more. It may be used by cronjobs later.
Next to the request handling a very simple build manger takes care of the serialization of image builds. The manager open images builders and create the image. On success the database will be updated and the image requests will show the image URL.
The build manger could delegate workers to build in parallel. The master/worker setup is possible but not planed. Depending on practical experience this feature will be added.
I ran the ansible found here against a demo server and is currently usable to create images for LEDE. To test the image creating process you can use a simple bash script. Please keep in mind that building is limited to supported devices. The demo server does not automatically follows the git repository.
The demo server is the cheapest Google VM I could find. If you have any advise where to go, please let me know!
- The update-server should setup (download tar, check packages, etc) on demand, not pre-setup by CLI.
network_profilescurrently do not work.
- The replacement table is not working jet.
- New images should be created if a package is upgrades.
- Libremeshs flavors need support
attended-sysupgradepackage need auto builds for all targets.