Comment 16 for bug 1475568

On Oct 07, 2015, at 03:00 PM, Łukasz Zemczak wrote:

>I was more thinking of something like 'tag=OTA-6' or something, so that
>this can be used for other purposes than just OTA's - any image could
>then be tagged for various reasons. The map idea would be a good hacky
>solution, but I think we should design it in a complete way. And we need
>to make sure that all the edge cases are handled, meaning:
>
> * Image tagged during image copy - the standard scenario for OTAs
> * Image tagged after image copy
>
>The old, existing images won't need to be handled as anyway a newer
>u-s-s from a newer OTA will be required for things to work. So images
>like OTA-4 etc. don't need to be detected (since there's no path that
>could lead to that being required). But still, we need to handle this
>rare case when someone makes a mistake and doesn't tag an image before
>copying it to a proper channel.

Okay, here's a concrete design strawman then.

We use the 'tag' key in version_detail as the way to label the OTA number.

When the device/channel's index.json is generated, the image specification
already has a version_detail key. We can add "tag=OTA-6" to that
version_detail value.

When the device checks for an update available, it calculates a winning update
path through a number of images. If the end-point image of the update
candidate has a version_detail key, it is already available in the
target_version_detail key of .Information(). Clients (e.g. system-settings)
will have to split that value on commas and parse it themselves, but that
should be easy.

Similarly, when the image is generated if the OTA number is known at that
time, you would add the tag to the version_detail in the .ini file,
e.g. /etc/system-image/config.d/01_channel.ini

This version_detail string is already available in the `version_detail` key of
.Information(). Again, clients would have to split and parse that but the
logic is the same.

As it turns out system-image client doesn't need to change at all to support
this. It already exposes both the current device's version_detail and the
target update's version_detail.

If an OTA number changes, it would require a regeneration of the index.json
file and potentially a new image generated. But only the data file containing
the /etc/system-image/config.d ini files would have to be regenerated.

What this doesn't handle is if an OTA number changes after a device has
already updated to that image. There's no way to get that new data onto the
device without doing an update.

If that's a use case we'd need to handle, then we have to be very careful that
we don't crush a network connection polling for new OTA numbers. I don't know
whether there's a push mechanism in place to handle this. OTOH, I think it
would be pretty confusing if people saw that their device was on OTA-6 one day
and then without ever updating their device, they saw it was on OTA-7.