[Bug 2002168] Re: apt-check needs to consider the pro client's esm cache for updates when esm is disabled

[Renan Rodrigo]

> I'd rather we have the implementation in update-manager reused by pro
and not the other way around, the whole thing should be meaningful for
users.

I see the point, but what I took into consideration for this particular
change is:

- Right now, update-notifier already depends on u-a-t implementation
(not only code, but the details, like the soon-to-be-gone 'never'
pinning on esm when disabled) to count and show esm updates when the
services are disabled. With this change, we can make it keep depending
on implementation, or depend on functionality directly, which is already
implemented in u-a-t.

- The change sent in the MR keeps all logic as-is for update-notifier,
including the dependency on the Pro Client for only those two things:
checking if esm is enabled or not, and counting esm upgrades when the
services are disabled.

- Even if u-a-t is to consume from update-notifier any information about
standard/security upgrades, it should still take care of esm, as we
discussed many times up to this point - Pro related things should live
in the Pro client. Take the esm cache itself: it would not make much
sense to create and maintain it under update-notifier, u-a-t should take
care of that. So, I understand and agree that a single implementation is
better and if we put esm upgrade counts to u-a-t and the other upgrade
counts in update-notifier, we'll end up with both tools depending on
each other to show complete and meaningful information; but it is not
clear (at least to me, sorry, maybe I miss some information) that
update-notifier should take this responsibility.

- I don ´t really understand how we can't treat phased updates in u-a-t
for instance (which today we do not, btw, by design) - update manager
has a python implementation and that's what update-notifier is relying
on anyway. If/when the apt phasing implementation gets to python-apt, it
will be available for u-a-t as well. But imho this is a separate issue
and can be solved in a separate thread.

- Last, let's say we agree that the way u-a-t should consume information
from update-notifier and/or vice-versa need to be reworked, this would
require a redesign of how this should work before actually implementing
something, and (you would not believe that) we have a deadline from the
products side - u-a-t needs to SRU changes by January 26th, and it will
impact update-notifier anyway. So, what I ask is: can we proceed with
updating update-notifier now adapting to the changes in the client? and
then (for next cycle, why not), I will be most happy to work on a better
design and implementation of how package upgrades can be advertised.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to update-notifier in Ubuntu.
https://bugs.launchpad.net/bugs/2002168

Title:
  apt-check needs to consider the pro client's esm cache for updates
  when esm is disabled

Status in update-notifier package in Ubuntu:
  New
Status in update-notifier source package in Xenial:
  New
Status in update-notifier source package in Bionic:
  New
Status in update-notifier source package in Focal:
  New
Status in update-notifier source package in Jammy:
  New
Status in update-notifier source package in Lunar:
  New

Bug description:
  [ Impact ]

  Currently, the Pro Client sets up ESM sources in the system's APT
  configuration to advertise ESM updates even when the service is
  disabled. This is undesired, as described in

  https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-
  tools/+bug/1990378

  The next version of ubuntu-advantage-client will not bring this
  configuration anymore, and will remove it from systems where it
  exists.

  Update Notifier relies on those unauthenticated ESM sources. It needs
  instead to rely on the Pro Client ESM apt cache to provide this
  information.

  If this is not changes, users will not see any ESM update or
  advertisement if they don't have the services enabled.

  The change in the reporting strategy will land in ubuntu-advantage-
  tools and will be SRUed back to Xenial, Bionic, Focal and Jammy.

  [ Test Plan ]

  In a Ubuntu LTS system (Xenial for esm-infra, bionic/focal for esm-apps):
    - Verify that the ubuntu-advantage-tools version installed is greater than 27.12
    - Verify that no ESM updates are reported when running /usr/lib/update-notifier/apt-check --human-readable
    - Install a version of update-notifier with the change (from -proposed, or from the MR branch if not uploaded yet)
    - Verify that ESM updates are when running /usr/lib/update-notifier/apt-check --human-readable

  [ Where problems could occur ]

  In the event of the change being implemented in a wrong/incomplete
  way, the side-effect is that users would not see the ESM updates, same
  as not implementing the change. However, it is simple enough to verify
  if this happens, and it is highly improbable that it does.

  [ Other Info ]

  Instead of reading the esm apt cache from the Pro Client, update-
  notifier could query the 'packages' API provided in the Client itself.
  However, for that to happen, it would make sense for the package to
  depend (or at least recommend) ubuntu-advantage-tools.

  Even using the esm apt cache would be a fair reason for update-
  notifier to recommend ubuntu-advantage-tools - but it is the same kind
  of coupling (relying on implementation) as reading the "never" pin
  from esm repositories, so there is no hard requirement to add the soft
  dependency.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/2002168/+subscriptions