Add esm-infra-legacy support for Trusty

[Lucas Albuquerque Medeiros de Moura]

[Impact]
As Trusty is reaching EOL of ESM support, we are now creating a new service called esm-infra-legacy to extend ESM support for more time.

This service will only be available and visible on Trusty, and users who are entitled to that service will need to run both of these commands to enable the service in their machine:

$ ua refresh
$ ua enable esm-infra-legacy

The first command will update the contract definitions on the machine, making it aware of the esm-infra-legacy service, and the second command enables it on the machine.

Additionally, we can see that esm-infra-legacy will be a standalone service, meaning that users won't need to have esm-infra already enabled before enabling that service. This also means that both esm-infra and esm-infra-legacy are completely independent of one another, in the sense that changes on esm-infra should not affect esm-infra-legacy and vice versa. However, there is one situation where esm-infra will impact esm-infra-legacy. We will better discuss that on the discussion section.

Finally, users should now see esm-infra-legacy output on status from now on, when attached and unattached. Users will also see that service on the output of ua help as well.

[Test cases]

The Trusty version of the client only has a subset of the integration tests we have on the other releases that support the client. Due to that, we will need to perform several manual tests to guarantee that the support for esm-infra-legacy is working and we are not affecting existing customers.

Therefore, besides running the current test for the Trusty package, we will run the following tests:

* Enabling esm-infra-legacy
  - User is attached to a subscription that is entitled to esm-infra-legacy
    - User can see esm-infra-legacy on ua help
    - User can enable esm-infra-legacy through ua enable esm-infra-legacy
    - User see esm-infra-legacy as enabled on the output of ua status
    - User can see esm-infra-legacy enabled on the output of apt-cache policy
    - User can disable esm-infra-legacy
    - User can see that esm-infra-legacy is disabled on the machine
    - User enables esm-infra-legacy again
    - User can detach with esm-infra-legacy enabled on the machine

* Interactions with esm-infra
  - User is attached to a subscription that is entitled to both esm-infra and esm-infra-legacy
  - User has esm-infra enabled
  - User can enable esm-infra-legacy
  - User can see both esm-infra and esm-infra-legacy as enabled on status
  - User can disable esm-infra-legacy and not affect esm-infra

* User that is not entitled to esm-infra-legacy
  - User is attached to a subscription
  - User cannot enable esm-infra-legacy
  - User can see the service on status, which will show the service as not entitled

* User that buys access to esm-infra-legacy
  - User is already attached to a subscription
    - User runs ua refresh
    - User enable esm-infra-legacy
    - User can see that the service is enabled on ua status

* User that is attaching a new subscription
  - User subscription can be either entitled or not to esm-infra-legacy
  - In both situations, when the user runs ua attach, they will verify that:
    - esm-infra will be enabled by default
    - esm-infra-legacy should not be enabled by default

* Upgrade scenarios:
  - User on Trusty running version <= 19.6
    - User is attached to a subscription
    - User has esm-infra enabled
    - User upgrades to new Trusty package
    - User is still attached and sees esm-infra as enabled
    - User can enable esm-infra-legacy

  - User on Trusty running version <= 19.6
    - User is attached to a subscription
    - User upgrades to new Trusty package
    - User enables esm-infra-legacy
    - User runs a do-release-upgrade
    - User will see that it is still attached
    - User still has esm-infra service enabled
    - User cannot see any indication of esm-infra-legacy on ua status and ua help

 - Users on other Ubuntu releases
   - Users should never see any mention of esm-infra-legacy service

[Discussions]

There are main aspects of the esm-infra-legacy service that need to be discussed here: The interaction between esm-infra-legacy and esm-infra and the disable strategy used for esm-infra-legacy.

Regarding the first aspect, the services should be independent of one another, however there is one situation where that doesn't happen. If the user disables esm-infra it will also disable esm-infra-legacy. That is because the esm-infra service in Trusty is disabled by performing the following steps:

* removing the service line from /etc/apt/auth.conf.d
* Create a preference file on /etc/apt/preferences.d with the following content:

Package: *
Pin: release o=UbuntuESM, n=trusty
Pin-Priority: never

This pin file is also disabling esm-infra-legacy because both services share the same origin, UbuntuESM. By fixing that, we would need to touch the logic related to disabling esm-infra, due to the extra risk tied to that change, we have discussed this with Product and we have concluded that we can proceed with the release even with this issue, that is because:

1) We believe it is highly unlikely that an user will disable esm-infra on Trusty today
2) When documenting about the esm-infra-legacy support, we can tell users what will happen when disabling the esm-infra service.

The second point is that we are disabling esm-infra-legacy differently then what we do for esm-infra. As we have mentioned, when disabling esm-infra we perform the two steps above, that is because we want users to still see the esm-infra packages on APT, even if the service is disabled. However, if we used the same estrategy for esm-infra-legacy, disabling esm-infra-legacy would also disable esm-infra, because of the preference file we already discussed. Because of that, when an user disables esm-infra-legacy, we will remove the source file on /etc/apt/sources.list.d/ to only affect the esm-infra-legacy service.

[Regression Potential]

We are adding a new service to the Trusty package. Since this is a new service and we will perform several tests already outlined to see how that service will appear in ua status and how it will interact with other services, we believe the regression potential here should be low.

[Andreas Hasenack (ahasenack)]

Hello Lucas, or anyone else affected,

Accepted ubuntu-advantage-tools into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubuntu-advantage-tools/19.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Lucas Albuquerque Medeiros de Moura (lamoura)]

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.

[Lucas Albuquerque Medeiros de Moura (lamoura)]

Even though the verification is already done, we intend to only release this package on April 30

[Andreas Hasenack (ahasenack)]

The do-release-upgrade issue is unfortunate, but I agree it's not being introduced in this update. It looks like we should think about it some more, though, given that trusty was just given some extra life, and would be good if trusty users could upgrade to the next release keeping their esm status/packages.

The DEP8 infrastructure is not ready to handle trusty updates anymore, and doesn't even recognize it as a valid release when I tried to trigger the missing tests manually. Looking at the test itself, though, it's very superficial (it only checks the help output), and the other tests performed for this SRU are vastly superior and of course check that the command-line tool runs.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-advantage-tools - 19.7

---------------
ubuntu-advantage-tools (19.7) trusty; urgency=medium

  * Add support to new esm-infra-legacy service (LP: #2060566)

 -- Lucas Moura <email address hidden> Thu, 28 Mar 2024 14:43:22 -0300

[Andreas Hasenack (ahasenack)]

The verification of the Stable Release Update for ubuntu-advantage-tools has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Andreas Hasenack (ahasenack)]

Marking the main devel task as invalid, because this only applies to trusty.