Provide "version_detail" for latest revision on server

[James Hunt]

Currently, the Information() D-Bus method provides the following something like:

current_build_number"="129"
device_name"="generic_amd64"
target_build_number"="131"
version_detail"="ubuntu=20141205.1,raw-device=20141205.1,version=129"
channel_name"="ubuntu-core/devel"
last_update_date"="2014-12-05 05:26:42"
last_check_date"="2014-12-05 15:41:43"

Ideally, it would also provide "version_detail" for the latest revision on the server, that is version_detail for target_build_number.

Even more ideally, it would break version_detail into chunks. Something like:

current_ubuntu_version=ubuntu=20141205.1
current_raw_device_version=20141205.1

... and for the latest revision found on the server, something like:

target_ubuntu_version=ubuntu=20141205.9
target_raw_device_version=20141205.2

For bonus points, this information would also be available via 'system-image-cli -i', maybe requiring an addition option like '--full' to avoid breaking existing consumers of 'system-image-cli -i' output.

Note that the command-line accessibility is potentially more important than the D-Bus interface due to the fact that system-image-cli -i provides the '-C' option to point it at an alternative installation.

[Barry Warsaw (barry)]

I'd like to avoid doing the split of the version_detail field in the client. It's guaranteed to be a comma separated list of key=value pairs, so it should be relatively easy for the consumer of this information to do the split.

The reason I'd like not to do it in the client is that we have a flat namespace in the mapping returned by .Information(), and the version_detail keys could be anything, so as implied in the description, we'd have to craft a naming scheme to prevent name collisions. At that point, any client would have to undo the naming scheme (e.g. a unique prefix) and then it seems just as easy for the client to do the split and not worry about de-prefixing.

I think it will be okay to include the target version detail in the -cli's --info output without an additional flag. While for practical purposes, the format of --information output is part of its API, I make no guarantees that it will not change or even be backward compatible.

One interesting possibility is to add a --json to --info, such that the output would be JSON compatible. That could make it easier to parse the cli's output.

Also, it's important to understand that retrieving the target's version_details isn't really possible currently, without actually downloading and installing the update. That's because the version_detail string is taken from the channel.ini file, and the target's version of that is embedded in the update's data file. It's not available even in the index.json file, so it's not like we can check for update and then provide that information (at least, not without a change to the server code to insert it into index.json, which isn't a bad idea, and I'll ask stgraber about that). E.g.

http://system-image.ubuntu.com/ubuntu-core/devel/generic_amd64/index.json

[James Hunt (jamesodhunt)]

stgraber has now added version_detail to index.json for all images.

[James Hunt (jamesodhunt)]

Hi Barry,

What's the current feeling now that we've got the potential to include this information in the s-i API? Does the argument about .Information() also apply to .UpdateAvailableStatus()?

(BTW, If there will not be a change to the .Information() API, could you clarify that the version_detail returned by Information() refers to the current version (rather than target) in the man page?).

[Barry Warsaw (barry)]

We can add target_version_detail just like target_build_number, thus:

If no CheckForUpdate has been called yet, the value is the empty string.

If there is no update available, target_version_detail == version_detail

If there is an update available, target_version_detail will be the version_detail string from the index.json file's Image that the update would leave you on.