[Description]
The canonical-server team is requesting a feature freeze exception for acceptance of an new version of ubuntu-advantage-tools. Version 19 will introduce an updated command line interface (UA Client) to simplify some interaction with Ubuntu Advantage support offerings. This version of ubuntu-advantage-tools depends on interaction with a new remote Contract API service for authentication and entitlement details.
[Rationale]
ubuntu-advantage-tools v.19 is currently under development against a Contract API spec but it has not yet been qualified against a functional (production, development) Contract API service. That contract service will not be made available to us until Feb 11th at earliest which doesn't leave enough time to validate ubuntu-advantage-tools' interaction with the remote API and resolve all major bugs by feature freeze date.
If we block the update to ubuntu-advantage-tools version 19, Ubuntu consumers will continue to use the existing ubuntu-advantage-tools. The current version requires authentication credentials for each different offering, whereas the new one offers a centralized and streamlined experience
[Timeline]
Our expectation is to have access to the UA Contract API backend service (ver.1) by Feb 11th at the earliest. The Contract API is under heavy active development which is changing the API spec in the process. When the Contract API service is available for testing, the Ubuntu Advantage integration testing against a functional API can begin to exercise both supported and unsupported platforms (kvm, lxc, baremetal). At this point any major bugs can be recognized and resolved.
[Risks]
Low-risk for Disco as ubuntu-advantage-tools will not allow enabling most support entitlements because it is not an LTS (where ESM or FIPS have support). This is a fairly simple command-line tool without a lot of moving pieces, the most significant complexity/risk in this new version comes from iteractions with the UA Contract API backend service to obtain auth tokens and request entitlement configuration details.
There is an apt hook for ESM being installed now that will run, and if it fails, it will print an error at the end of transactions:
<juliank|away> andreas: not near a computer (except my phone), and can't edit launchpad, but the only risk from the apt hook is it failing and printing error messages at the end of apt update/install/upgrade/etc
This new client is a rewrite from bash to python and is used only to enable/disable apt repositories, interact with motd and livepatch. The move to python makes it a bit easier to test functionality. We will have both integration tests and unittest coverage for all significant features to ensure that the features are well vetted prior to release.
There's still some hours until Feature Freeze, but so far the FFe looks sane. I would, in overall, recommend uploading the 19 version to the archive as soon as possible and use the time before release to work on all the rough edges. We'd of course like all devel uploads to be rock-solid, but there's also nothing wrong with uploading a base version of a rewritten app and then working (after FF) on making it shiny.
As for the FFe, you mention that the new version is a rewrite in python. What new dependencies would it introduce? Are all of them in main?