removed application level update as covered by packege-based updates
This commit is contained in:
@@ -124,7 +124,6 @@ Other update strategies should be considered when:
|
||||
The following alternatives are addressed in separate ADRs:
|
||||
|
||||
- package-based updates;
|
||||
- application-level updates;
|
||||
- container-based updates;
|
||||
- versioned filesystem trees;
|
||||
- hybrid update strategies.
|
||||
|
||||
@@ -131,7 +131,6 @@ Another approach should be considered when:
|
||||
The following alternatives are described in separate ADRs:
|
||||
|
||||
- full-system image updates;
|
||||
- application-level updates;
|
||||
- container-based updates;
|
||||
- versioned filesystem trees;
|
||||
- hybrid update strategies.
|
||||
|
||||
@@ -182,9 +182,7 @@ What is the installable artifact?
|
||||
- a full image;
|
||||
- a filesystem;
|
||||
- a package;
|
||||
- an application;
|
||||
- a container;
|
||||
- an individual file;
|
||||
- a data set.
|
||||
|
||||
### 2.2. Delivery Method
|
||||
@@ -390,50 +388,7 @@ A package manager alone solves only part of the OTA problem.
|
||||
|
||||
---
|
||||
|
||||
## 5. Updating Individual Applications
|
||||
|
||||
Application updates resemble package-based updates, but the managed unit is a specific application or service rather than an operating-system component.
|
||||
|
||||
An application may be delivered as:
|
||||
|
||||
- an executable file;
|
||||
- an archive containing libraries and resources;
|
||||
- an application bundle;
|
||||
- a custom package;
|
||||
- a separate filesystem tree;
|
||||
- a container image.
|
||||
|
||||
### 5.1. Advantages
|
||||
|
||||
- small update size;
|
||||
- fast release cycle;
|
||||
- independence from base operating-system releases;
|
||||
- only one service may need to restart;
|
||||
- different teams can manage different components.
|
||||
|
||||
### 5.2. Disadvantages
|
||||
|
||||
- compatibility with the platform must be managed explicitly;
|
||||
- interacting services may become version-incompatible;
|
||||
- stable APIs or ABIs are required;
|
||||
- data migrations complicate rollback;
|
||||
- the overall product no longer has one obvious version.
|
||||
|
||||
Instead of a simple system version such as `3.2.0`, the product may have a combination such as:
|
||||
|
||||
```text
|
||||
Base OS: 3.2
|
||||
Device service: 7.4
|
||||
User interface: 5.1
|
||||
Communication stack: 2.8
|
||||
Configuration schema: 4
|
||||
```
|
||||
|
||||
This is not necessarily bad, but the complexity must be accepted and controlled deliberately.
|
||||
|
||||
---
|
||||
|
||||
## 6. Container-Based Updates
|
||||
## 5. Container-Based Updates
|
||||
|
||||
A container image may be used as the delivery and execution unit for an application.
|
||||
|
||||
@@ -448,7 +403,7 @@ Host operating system
|
||||
|
||||
Updating an application may consist of downloading a new image and switching to it.
|
||||
|
||||
### 6.1. Advantages
|
||||
### 5.1. Advantages
|
||||
|
||||
- the application is delivered with a significant part of its dependencies;
|
||||
- strong component isolation;
|
||||
@@ -457,7 +412,7 @@ Updating an application may consist of downloading a new image and switching to
|
||||
- reuse of existing build and registry infrastructure;
|
||||
- applications can have independent release cycles.
|
||||
|
||||
### 6.2. Disadvantages
|
||||
### 5.2. Disadvantages
|
||||
|
||||
- the container runtime becomes part of the trusted platform;
|
||||
- storage and memory requirements increase;
|
||||
@@ -478,7 +433,7 @@ Configuration -> signed documents
|
||||
|
||||
---
|
||||
|
||||
## 7. Atomic Filesystem Trees and Versioned System States
|
||||
## 6. Atomic Filesystem Trees and Versioned System States
|
||||
|
||||
Between full images and traditional packages are approaches in which the system is represented as a versioned filesystem tree.
|
||||
|
||||
@@ -495,7 +450,7 @@ The central idea is:
|
||||
|
||||
> The update is neither an in-place set of file changes nor necessarily a complete block image. It is a complete versioned filesystem state.
|
||||
|
||||
### 7.1. Advantages
|
||||
### 6.1. Advantages
|
||||
|
||||
- atomic switching between versions;
|
||||
- reproducible system state;
|
||||
@@ -504,7 +459,7 @@ The central idea is:
|
||||
- fewer changes to the running system;
|
||||
- a useful compromise between images and packages.
|
||||
|
||||
### 7.2. Disadvantages
|
||||
### 6.2. Disadvantages
|
||||
|
||||
- more complex storage model;
|
||||
- additional build-tooling requirements;
|
||||
@@ -517,7 +472,7 @@ This mechanism can be attractive, but its benefits appear only when the entire s
|
||||
|
||||
---
|
||||
|
||||
## 8. Binary Delta Updates
|
||||
## 7. Binary Delta Updates
|
||||
|
||||
A binary delta contains the difference between a known old version and a new version rather than the complete new artifact.
|
||||
|
||||
@@ -542,14 +497,14 @@ It may be applied to:
|
||||
|
||||
It is therefore more accurate to treat a binary delta as a **delivery optimization**, not as an update unit.
|
||||
|
||||
### 8.1. Advantages
|
||||
### 7.1. Advantages
|
||||
|
||||
- lower network traffic;
|
||||
- faster download over slow connections;
|
||||
- reduced mobile or satellite data cost;
|
||||
- the ability to update large artifacts through a constrained channel.
|
||||
|
||||
### 8.2. Disadvantages
|
||||
### 7.2. Disadvantages
|
||||
|
||||
- the delta depends on a specific source version;
|
||||
- multiple update paths may need to be stored or generated;
|
||||
@@ -576,7 +531,7 @@ Reduced network traffic is therefore purchased with additional system complexity
|
||||
|
||||
---
|
||||
|
||||
## 9. Updating Individual Files and Data
|
||||
## 8. Updating Individual Files and Data
|
||||
|
||||
The smallest update unit is an individual file or a small group of files.
|
||||
|
||||
@@ -611,7 +566,7 @@ Artifact size does not determine the cost of failure.
|
||||
|
||||
---
|
||||
|
||||
## 10. Hybrid Strategies
|
||||
## 9. Hybrid Strategies
|
||||
|
||||
In most complex products, the most reasonable solution is a combination of several mechanisms.
|
||||
|
||||
@@ -643,14 +598,14 @@ This allows different properties to be applied to different components.
|
||||
|
||||
For the base system, the priority may be reliability and reproducibility. For maps, it may be minimal network traffic. For applications, rapid release. For certificates, strict coordination and limited validity periods.
|
||||
|
||||
### 10.1. Advantages
|
||||
### 9.1. Advantages
|
||||
|
||||
- each data type receives an appropriate mechanism;
|
||||
- the entire system does not need to be updated for a small change;
|
||||
- reliability, bandwidth, and release speed can be optimized independently;
|
||||
- the design reflects the real lifecycle of each component.
|
||||
|
||||
### 10.2. Disadvantages
|
||||
### 9.2. Disadvantages
|
||||
|
||||
- multiple mechanisms must be designed, tested, and maintained;
|
||||
- compatibility modelling becomes more complex;
|
||||
@@ -673,7 +628,7 @@ Without such a reason, an additional mechanism only increases system complexity.
|
||||
|
||||
---
|
||||
|
||||
## 11. Why There Is No Best Strategy
|
||||
## 10. Why There Is No Best Strategy
|
||||
|
||||
The question:
|
||||
|
||||
@@ -693,7 +648,7 @@ The correct question is:
|
||||
|
||||
> **What constraints does our system have, and which update properties matter most?**
|
||||
|
||||
### 11.1. Reliability
|
||||
### 10.1. Reliability
|
||||
|
||||
What happens if power is lost in the middle of installation?
|
||||
|
||||
@@ -703,7 +658,7 @@ Is manual recovery acceptable?
|
||||
|
||||
The more expensive physical access is, the more valuable atomic installation and automatic rollback become.
|
||||
|
||||
### 11.2. Storage Capacity
|
||||
### 10.2. Storage Capacity
|
||||
|
||||
Is there enough space for two complete system images?
|
||||
|
||||
@@ -713,7 +668,7 @@ How many previous versions must be retained?
|
||||
|
||||
Limited storage may exclude some approaches or require a more complex streaming installation process.
|
||||
|
||||
### 11.3. Connectivity Cost and Quality
|
||||
### 10.3. Connectivity Cost and Quality
|
||||
|
||||
Does the device use Ethernet, Wi-Fi, mobile, or satellite connectivity?
|
||||
|
||||
@@ -725,7 +680,7 @@ Can downloads safely resume?
|
||||
|
||||
Over an expensive link, the complexity of delta updates may be justified. On a cheap local network, a full image may be simpler and cheaper to operate.
|
||||
|
||||
### 11.4. Update Frequency
|
||||
### 10.4. Update Frequency
|
||||
|
||||
Is the system updated once per year or several times per day?
|
||||
|
||||
@@ -733,7 +688,7 @@ Rare system updates and frequent data updates naturally require different mechan
|
||||
|
||||
The more frequently a component changes, the more valuable an independent release cycle becomes.
|
||||
|
||||
### 11.5. Component Independence
|
||||
### 10.5. Component Independence
|
||||
|
||||
Can the components really be updated independently?
|
||||
|
||||
@@ -743,7 +698,7 @@ Is compatibility between versions maintained?
|
||||
|
||||
Independent delivery does not imply independent operation. If application version `5` requires library version `3`, the two must still be coordinated.
|
||||
|
||||
### 11.6. Cost of Failure
|
||||
### 10.6. Cost of Failure
|
||||
|
||||
What happens if an update is unusable?
|
||||
|
||||
@@ -751,7 +706,7 @@ Does the device temporarily lose a minor feature? Stop a production line? Make a
|
||||
|
||||
The same technical failure may have completely different consequences in different products.
|
||||
|
||||
### 11.7. Downtime Requirements
|
||||
### 10.7. Downtime Requirements
|
||||
|
||||
Can the device be rebooted?
|
||||
|
||||
@@ -761,7 +716,7 @@ Is restarting one service acceptable?
|
||||
|
||||
Some systems may update overnight with a full reboot. Others must preserve their primary function almost continuously.
|
||||
|
||||
### 11.8. Support Lifetime
|
||||
### 10.8. Support Lifetime
|
||||
|
||||
How many years will the device remain in service?
|
||||
|
||||
@@ -771,7 +726,7 @@ Will a team still be available to maintain a complex mechanism ten years from no
|
||||
|
||||
The OTA architecture must not only be technically possible today. It must remain maintainable throughout the entire product lifecycle.
|
||||
|
||||
### 11.9. Team Capabilities
|
||||
### 10.9. Team Capabilities
|
||||
|
||||
A complex solution does not become a good solution merely because it is technically elegant.
|
||||
|
||||
@@ -789,7 +744,7 @@ If potential traffic savings require a mechanism the team cannot operate reliabl
|
||||
|
||||
---
|
||||
|
||||
## 12. Strategy Is a Consequence of Constraints
|
||||
## 11. Strategy Is a Consequence of Constraints
|
||||
|
||||
OTA selection should not begin with a technology name.
|
||||
|
||||
@@ -834,7 +789,7 @@ If the process starts with a tool, the architecture will be forced to fit the to
|
||||
|
||||
---
|
||||
|
||||
## 13. Preliminary Comparison
|
||||
## 12. Preliminary Comparison
|
||||
|
||||
The following table is not yet a complete decision matrix. It only summarizes the primary properties of the approaches discussed in this chapter.
|
||||
|
||||
@@ -855,7 +810,7 @@ The same approach may be strong or weak depending on context.
|
||||
|
||||
---
|
||||
|
||||
## 14. What Comes Next
|
||||
## 13. What Comes Next
|
||||
|
||||
This chapter describes the space of possible solutions, but it does not declare a single winner.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user