As the creator of aktualizr-lite, I often underestimate the difficulty in understanding what aktualizr-lite is trying to do. Rather than typing the same few things in Slack over and over, I thought I'd try to write down what aktualizr-lite is "thinking".
First, let's step back on why aktualizr-lite needs to "think". A couple of years ago I got frustrated with Uptane. It's a brilliant, secure concept. However, it's about telling each device what it should be. That brings a bunch of complexity. A device's only goal should be "I want to be the latest stable Target available to me". That's why aktualizr-lite was born, and that's the simplest explanation of what aktualizr-lite is "thinking".
What It's Really Thinking
Aktualizr-lite's daemon runs a pretty simple forever-loop. It asks two questions:
- What Target am I running? Call this
cur-target - What’s the latest Target available to me? Call this
new-target
If new-target > cur-target we need to perform an update. It's really that simple.
It's Never That Simple
It's true, I've lied. However, the mental model above is sufficient for reasoning about your devices 95% of the time. What can get tricky with our system is that we allow you to change what Docker Compose Applications your device should run. This sounds like a different scenario, and the stimulus of the change comes from fioctl/fioconfig. However, the result is the same. Our "desired target" (the ostree hash + list of apps to run) is not equal to our current target. So aktualizr-lite knows it needs to do an update. In this case the "update" is changing the apps running on the device.
What's the Catch?
Okay - aktualizr-lite had to be taught about one important thing: rollbacks. In the event a device can't boot its current Target, the bootloader will have it boot the previous Target. In this situation cur-target is less than new-target. However, we know that Target is bad, and we won't try to install it again. The daemon will wait until there's a newer new-target.
What About Device Tags?
Here's how to think about device tags. As you push code to your Factory, we create new Targets. These targets will be tagged (a device tag). By convention we usually make this tag the same as the Git branch you are on. Your Factory's targets.json can start to grow big. However, the targets.json served to each device is what we call a "condensed-targets". This file is only Targets that your device is subscribed to. So while your Factory's targets.json might look like:
Target-1 - tag=devel
Target-2 - tag=devel,master
Target-3 - tag=master
Target-4 - tag=devel
You device configured on the "master" tag will only see:
Target-2 - tag=devel,master
Target-3 - tag=master
In other words it won't even know there's a Target 1 or Target 4. So aktualizr-lite is really just trying to keep up-to-date.