We are excited to announce the Mender 3.0 LTS release!
Mender 3.0 introduces new features to get full control over the progress of the update, both centrally through Synchronized update as well as with device application through brand new Mender Device-side API using D-Bus.
We also released maintenance releases 2.7.1 and 2.6.2 which contain stability improvements, but no new features. If you are on the 2.7 or 2.6 branch and not ready to go to 3.0, you may consider upgrading to these maintenance releases for now. Read more in the 2.7 Changelog and 2.6 Changelog to see the issues addressed in these. The rest of this post will focus on the new features of the Mender 3.0 release.
Synchronized Update ensures consistency of software versions across the device fleet, even amid an unreliable environment and failures. This is important in deployments where software versions running on the devices need to be the same, such as for co-located devices for transportation or a building.
In such cases, using Synchronized Update will ensure consistency, shorter maintenance windows, end user control and higher uptime of the device fleet without need for time-consuming manual intervention and “clean up” after a failure.
Synchronized Update allows you to pause an update deployment once it reaches a given state on the devices. Once a device reaches this state it will pause until it receives instructions to either continue or abort the update process, in which case it will attempt to roll back to the previous version.
There are several use cases enabled by this feature, covered in separate sections below.
Shorten maintenance windows: Pause before Install
Downloading large software artifacts to devices can take a long time, as wireless connectivity is the most common and can often be unpredictable in terms of throughput and intermittency.
At the same time, downloading software does not cause any downtime in itself so it can usually be allowed to run over a longer period of time across the fleet without any maintenance window, as long as the next states of the update process can be controlled. This is where Pause after before Install comes in.
For example, assume it takes 5 days for the last device to fully download a software artifact, and 3 minutes to reboot devices into the new software. If you Pause after Download (i.e. before Install) you can start the deployment on Monday and have zero downtime, and no need for a maintenance window, until all the devices have reached the paused state (expected on Friday). At this point you can announce a short maintenance window (at least 3 minutes to allow for the reboot) and Continue the update process during this window.
Without Synchronized update, your devices could have rebooted, or failed the update, and thus require a maintenance window at any point from when you started the deployment until all devices successfully updated, which would be many days. But with Synchronized update you are in full control of the maintenance window and can reduce it to minutes.
The screenshot below shows configuring a deployment to pause after Download (before Install).
User-controlled downtime: Pause before Reboot
When doing A/B system updates, the only downtime users of the device will experience is during the reboot. This is because the download happens to a separate partition, and the device is fully operational during this time.
The Install state simply switches the boot configuration so that the device will boot from the updated partition the next time it reboots, regardless if it is rebooted by Mender or any other way.
This means that you can Pause a deployment before Reboot and then rely on the end user of the device to reboot whenever they are ready. After the reboot, Mender will pick up the update process and finalize it.
Ensure quality: Pause before Commit
The new software is fully installed and running at the Commit state. Adding a Pause here allows you to do final quality checks of the new software version before making it the permanent version. This is also something you can let end users of the device decide (also see Device-side API below).
Note that although A/B system updates are used as the example update type above, Synchronized update is supported for all types of updates.
Synchronized Update is only available in Mender Enterprise.
To support and complement Synchronized Update a new Device-side API, based on D-Bus, is introduced in Mender 3.0.
In this new Device-side API, Mender supports controlling the updates on a device, through pausing, continue and abort. This enables a new set of use cases for devices with a display, or which are otherwise controlled by a user.
For example, you can now easily implement an Updates enabled / disabled toggle in the device UI. The UI will simply tell the Mender client over the Device API to Pause all updates before Download or Install (depending on your preference). Once the user is ready, or as detected by idle usage of the device, updates can be enabled again.
The Device-side APIs will be extended further in future releases.
Relation to State scripts
If you are familiar with Mender, you might know that State scripts can also be used to carry out actions in scripts between states in the Mender client, and so it would seem to cover similar use cases as the Device-site API.
However, the initial features of the Device-side API are better suited for situations where you interact with end users and the length of the pause may be hard to predict. State scripts, on the other hand, are better suited for making required changes such as migrating a configuration file schema or waiting for network connectivity.
Device-side APIs are available in all plans and are distributed as open source. See the API specification in the Mender documentation.
The Mender UI has been significantly improved in terms of managing devices with different authentication states.
The new Devices UI in Mender 3.0 unifies all devices in a single place and allows you to filter and do batch operations on them regardless of the authentication state they are currently in. This ensures operating on the devices has a consistent experience, making it easier to use and saving you time when working with your devices.
The authentication state is still available as a filter, in case you would like to see all rejected devices, for example.
In previous versions of Mender, the different authentication states such as Pending and Rejected were shown under separate tabs in the UI. However, this leads to some confusion when trying to filter to find a specific device, or carrying out batch operations such as “accept these 5 rejected devices”, or “filter the rejected device with MAC address X”
This change was introduced as a result of ongoing user feedback and we would be happy to hear what you think.
Here are some pages with more information to get you started with the new features of Mender 3.0:
If you are getting started with OTA updates, or do not have time to integrate the Mender client with your board for robust A/B system updates, there are several resources available to you!
The Board Integrations category in Mender Hub is a community site to contribute, reuse and maintain Mender board integrations.
We are also happy to help with consulting services to enable verified Mender support for your board!
We appreciate your general feedback on Mender, be it positive or need for improvement, in the Mender Hub General Discussions forum. Your continued feedback ensures Mender will meet your needs even better in the future!
If you believe you have encountered a bug, please submit your report at the Mender JIRA issue tracker.
We hope you enjoy the new features and are looking forward to hearing from you!