Page MenuHomePhabricator

Incomplete puppet fact generation for packages held back for adding new binary packages
Closed, DeclinedPublic

Description

When checking for missing security updates I noticed that the servermon package list for copper showed an inconsistent status for xdelta:
Installed Version: ----
Available Version: 1.1.3-9.1

I incorrectly blamed servermon, but Alex pointed out that this is already wrong on the puppet fact level:
<package name="xdelta" new_version="1.1.3-9.1" origin="Debian" source_name="xdelta" />

After some poking we tracked down the problem to /usr/local/bin/apt2xml's handling of package updates which introduce new binary packages. This happens due to the simulation of a dist-upgrade by apt2xml instead of a regular upgrade.

On e.g. copper there's two packages which are held back (since their installation would install new binary packages): linux-meta and openstack-pkg-tools;
the latter is the package which would pull in xdelta.

Ways of handling this:

  • Filter it at the apt2xml level (if a package does not have an available version, don't add it to the list at all)
  • Inform at the servermon level the user of that edge case via a tooltip as proposed in https://github.com/servermon/servermon/issues/157

Moritz prefers the former with the following justification:

I think apt2xml should rather filter out the "available" version if the "installed" version is non-existant, because 
a) at the moment the package isn't installed yet and thus no update is required
b) at the moment an update of openstack-pkg-tools is made, apt would automatically pull in the latest version of xdelta anyway

Event Timeline

MoritzMuehlenhoff raised the priority of this task from to Needs Triage.
MoritzMuehlenhoff updated the task description. (Show Details)
MoritzMuehlenhoff added a project: SRE.
MoritzMuehlenhoff renamed this task from Incomplete puppet fact generation for packages help back for adding new binary packages to Incomplete puppet fact generation for packages held back for adding new binary packages.Nov 24 2015, 2:27 PM
MoritzMuehlenhoff set Security to None.

That specific behavior was added in https://github.com/servermon/servermon/commit/d8a25f0c2dda2a5465096b2af67c65dd204bf989

when dist_upgrade was set to True. Keeping the dist_upgrade to True is technically correct as we want to be able to see upgrades for all packages. Hence, both proposals are better than setting dist_upgrade=False. My inclination is to go with the tooltip approach and not remove data from the fact, since it allows a more complete image of a host to be displayed in servermon.

@faidon, Since you added the dist_upgrade=True change, any preferences ?

I think we should keep dist_upgrade=True. The linux-meta case -or the equivalent in Debian upstream, linux-image-amd64- is actually a good example case for this: we do want these kernel upgrades to appear in servermon, especially since some of these are actually flagged as security updates as well.

MoritzMuehlenhoff claimed this task.

Ok, I'm convinced. Let's close this one, no need to keep it open for the servermon tooltip (tracked at github anyway): https://github.com/servermon/servermon/issues/157