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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1475568 Title: Use OTA terminology in system settings To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1475568/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
