Comment 2 for bug 2060566

I have performed the verification for this proposed changed.
Attached to this comment, are the test results we have obtained when running a custom script that:

1) Launches a trusty lxd container
2) Install the proposed version of the Pro client
3) Checks that esm-infra-legacy appears on ua status when the user is unattached
4) Attaches to a license that is entitled to esm-infra-legacy
5) Verify the service is not enabled by default
6) Enables the esm-infra-legacy service manually
7) Checks that esm-infra-legacy is enabled on ua status
8) Disables esm-infra-legacy
9) Checks that esm-infra-legacy is disabled and esm-infra is still enabled
10) Enable the service again and checks that ua status reflect that
11) Detach from subscription
12) Attach to a subscription that is not entitled to esm-infra-legacy
13) Check that ua status show the service as not entitled
14) Detach from that subscription

The script that perform this verification is also attached with the test result.
Additionally, we are also adding the result of the existing integration tests for the Trusty package.

We have also tested if esm-infra-legacy doesn't appear on any other release besides Trusty.
We have looked on a Xenial instance and we have checked that both unattached and attached users do not see that service on pro status, even if we attached with a subscription token that is entitled to esm-infra-legacy.

Another manual test performed was for the situation where an user:

1) User has older version of the Pro package installed (i.e. 19.6)
2) Is attached to subscription not entitled to esm-infra-legacy
3) Upgrades to latest version of package
4) See that esm-infra-legacy now appears on ua status, but not entitled
5) Buys support for esm-infra-legacy
6) Runs ua refresh
7) It can see now that the service appears as entitled on ua status
8) user enable the service through ua enable esm-infra-legacy

We have coordinated that test with the Contract Server team and we were able to confirm all of the above scenarios.

Finally, we were not able to perform one of the proposed tests, the do-release-upgrade one. We have found out that if an user has esm-infra enabled and has packages installed from that service, do-release-upgrade fails. That is because, on Trusty, do-release-upgrade thinks that esm-infra sources are Third-party sources and disables them. Which in turn, breaks the dependency chain of upgrading from Trusty to Xenial, as these packages don't have a "viable" candidate in Xenial anymore. This is a long living bug, that was not introduced in this package. Due to that, we will not act upon it right now.