Merge lp://qastaging/~didrocks/ubuntu-release-upgrader/add_telemetry into lp://qastaging/ubuntu-release-upgrader

Keep in mind that it is possible to from one release to multiple releases e.g. from xenial to artful or bionic. So without knowing the database structure I think it would make sense to also record the "To" release. You can find this in DistUpgradeController.py.

I'm also curious about how this information will be used because the use cases might benefit from gathering additional information like the version of release upgrader being used or environmental variables set.

Otherwise there are a couple of typos and one nitpick to have a look at.

Thanks for the review!
There isn't a fixed database structure schema. However, keep in mind that ubuntu-report gather this results (as well as installers one) under some subfields on the json, alongside collecting a lot of others information.
So basically, we have the "To" and a lot of other details. Moreinfo on https://github.com/ubuntu/ubuntu-report.

For now, we collect those details, similarly than for ubiquity, and we'll organize them next cycle if nobody on IS step up first.

Typos fixed and pushed. Thanks!

This looks good to me to merge and upload after the one change is made.

While this may be more useful for the failure case you might consider including what components (-updates, -security, main, universe, etc...) are enabled on the system that was upgraded. Here's an example from an upgrade log file.

2018-05-12 20:32:36,997 DEBUG found components: {'bionic-updates': {'main', 'universe', 'multiverse', 'restricted'}, 'bionic-security': {'main', 'universe', 'multiverse', 'restricted'}, 'bionic': {'main', 'universe', 'multiverse', 'restricted'}}

We don't want to include the enabled components for now, but thanks for the suggestion! I'll fix the current uptime comment.

Thanks again for the review :)

Tested artful -> bionic upgrade with this code and it reports the expected telemetry data.