Commit 30c8edca authored by Peter Senna Tschudin's avatar Peter Senna Tschudin

software-distribution-and-updates.md: Differentiate user/operator use cases

This change makes it explicit the differences between user-driven and
operator-driven use cases and includes a reword of the Linux
distributions and custom applications section.
Signed-off-by: Peter Senna Tschudin's avatarPeter Senna Tschudin <peter.senna@collabora.com>
parent 94cb1279
......@@ -20,12 +20,20 @@ criteria:
* Rollback capabilities
* Configurable permissions for applications to access user data and system resources
This document describe components that provide features of software
distribution and update that can be combined to meet Apertis requirements.
OSTree can handle the base operating system on the devices; Flatpak and Docker
can handle applications on the devices; hawkBit can manage the software stack of
a fleet of devices on the field for operator-driven use cases; and Flathub can
act as an appstore and backend for user-driven use cases for Flatpak
applications.
### System updates and rollback
[System updates and
rollback](https://designs.apertis.org/latest/system-updates-and-rollback.html)
was written as a description of a proof of concept, and contains detailed
documentation about system updates and rollback of updates. The two documents are
complementary with some overlap between the two.
was written to describe in details the concepts of updates and rollbacks. The
two documents are complementary with some overlap between them.
### Linux distributions and custom applications
......@@ -41,15 +49,24 @@ usually possible but may involve updating all software.
In Debian based distributions a file with .deb extension is a package that
contains meta-data and the files for installing one piece of software such as
an application or a library. A package is built from source code for one
specific distribution release, meaning that packages cannot be safely reused on
different releases of a Linux distribution.
A custom application is an application that is not part of the distribution.
When using the traditional package-based approach, the custom application
developers are required to create and maintain one package for each release of
each Linux distribution supported. Supporting multiple releases and multiple
distributions is time consuming, and is usually perceived as overhead, slowing
down the custom application development.
specific distribution release(or for an specific API and ABI), and a package
cannot be safely reused on different releases of a Linux distribution because
of differences in API and ABI.
An application is labeled as custom when it is not part of the distribution.
The developers of custom applications depend on the stable API and ABI to
produce applications that can run on the distribution. If the custom
application needs to run in multiple releases of a distribution the developers
are required to do a lot of work to release and maintain different packages of
the application for each release of the distribution.
This maintenance process for custom applications using the traditional
package-based approach is time consuming and usually regarded as slowing down
the application development. To minimize the maintenance burden this document
presents Flatpak and Docker that provide methods for decoupling applications
from the base operating system considerably alleviating the developers from the
need of maintaining their application for different releases of the
distribution.
### Software updates
......@@ -58,12 +75,8 @@ most common goals of an update are fixing bugs, removing security
vulnerabilities, and adding new features. Updating a software component may
also involve updating the chain of dependencies of that software component.
A few solutions were created to alleviate the problems custom application
developers have on Linux distributions, such as the overhead of maintaining
packages for multiple releases of various distribution. This document describes
two that are made for complementary use cases: Docker and Flatpack. This
document also describes OSTree as a solution for base operating system update
that offers atomic updates and reliable rollback capabilities.
For the update of applications this document present Docker and Flatpack. For
the update of the base operating system this document presents OSTree.
### Software distribution
......@@ -74,15 +87,15 @@ layer for packages. Software distribution can include authorization, inventory,
and deployment management.
The software distribution infrastructure for traditional tools such as
`apt-get` basically consists of static content providers, and has no
intelligence to make decisions tailored to individual users. Making software
`apt-get` basically consists of static content providers, and it is not
designed to make decisions tailored to individual users. Making software
distribution decisions based on payment, user profile, hardware profile, and
other business rules is usually not possible using only the package and
repository infrastructure of standard Linux distributions.
This document describe components that provide features of software
distribution that can be combined to meet Apertis requirements: OSTree,
Flatpak, Docker, hawkBit and Flathub.
hawkBit can manage the software stack of a fleet of devices on the field for
operator-driven use cases; and Flathub can act as an appstore and backend for
user-driven use cases for Flatpak applications.
## Terminology
......@@ -135,9 +148,21 @@ Base operating system can be handled as a monolithic unit with immutable
filesystem, meaning that applications deployed as part of the Base operating
system cannot be updated separately nor can be removed at run time.
## Use cases
This document covers two groups of use cases: operator-driven and user-driven
use cases which can be used separately or combined.
Operator-driven are use cases in which the user may not have control over the
software to be installed, removed and updated. In cases where the
infrastructure is in place the operator, and not the user, have control over
software to be installed, removed and updated.
User-driven use cases are likely to be an extension of the Operator-driven use
cases, as the operator may still have full control over the base operating
system. However when the infrastructure is in place, the user may have limited
powers to install and remove user-facing applications, tied or not to payments.
### Connectivity box
A connectivity box is a headless embedded device that provides a landing zone
......@@ -156,6 +181,12 @@ external devices such as smartphones, and USB keys.
A monitoring device is a single-purpose headless appliance that captures an
audio/video stream and sends it to remote servers for processing.
### Digital signage
A digital signage appliance displays advertising contents over one or more
panels. It can either source the contents to display locally or from a remote
server.
### Infotainment system
An infotainment system offers access to a large set of applications and content
......@@ -164,12 +195,6 @@ Applications let users watch movies, listen to music, browse the internet, play
games and much more. Users may be able to install applications from a store,
which may be free or require payments.
### Digital signage
A digital signage appliance displays advertising contents over one or more
panels. It can either source the contents to display locally or from a remote
server.
## Non-use-cases
* Product development: during product development developers need to privilege
flexibility over robustness. However robustness is of primary importance in
......@@ -303,7 +328,7 @@ recommend to use either Flatpak or Docker.
### Flatpak and Docker
Flatpak is a feature rich solution for application distribution and updates
that offer a powerful decoupling from the system. It gives the application
that offer decoupling from the system. It gives the application
developer greater freedom, and gives the user greater control and greater
execution insulation when compared to more conventional packaging and
distribution systems such as dpkg and apt-get. Flatpak uses libostree under the
......@@ -325,9 +350,9 @@ simultaneously but we do not advise to split a single application or a single
service between the two.
## Deployment management
Deployment management services are meant to let operators control which
applications are installed on the fleet of devices on the field, with some
tools also offering control for managing the base operating system.
Deployment management services are backend services meant to let operators
control software installed on the fleet of devices on the field. These tools
are mostly focused on operator-driven use cases.
### Eclipse hawkBit
Eclipse hawkBit is a back-end framework for managing software updates to edge
......@@ -392,9 +417,10 @@ interest in the feature. It does not provide any remote management solution.
* Use Flatpak or Docker for encapsulation, distribution and updates of
applications and services as bundles.
* Use Flathub and Docker registry for storage and content delivery systems
* Operator-driven and user-driven use cases have different requirements and
tools with no one-size-fits-all solutions, so different approaches must be
considered
* Operator-driven and user-driven use cases have different requirements.
At this stage trying to comeup with a one-size-fits-all solution may impose
restrictions instead of adding value. We believe that the building blocks proposed
are a good starting point for considering approaches for different use cases.
* For operator-driven management, provide integration with hawkBit and
Microsoft Azure IoT Edge
* Open point: should Apertis provide a default hawkBit instance for testing
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment