Looks like we have 3.1.1-1 installed, not 4.1.1-1+0~20180819152012.3+stretch~1.gbpd95942 (which is available)

Do we have to install the php7.2-redis package?

and / or https://stackoverflow.com/questions/50283298/php7-2-fpm-can-t-install-redis

IIRC (we ran into similar issues on Vagrant in T213016: Sometimes Redis does not work on MediaWiki-Vagrant with PHP 7.2) there is no php7.2-redis, just a single php-redis which works with all versions of PHP. The Wikimedia apt repo used to have the wrong version of it pinned, but I believe that has been fixed since.

In modules/contint/manifests/packages/php.pp we're doing ensure => latest

reedy@deploy1001:~$ apt-get install -s php-redis
NOTE: This is only a simulation!
      apt-get needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following package was automatically installed and is no longer required:
  python-configobj
Use 'apt autoremove' to remove it.
Suggested packages:
  redis-server
The following packages will be upgraded:
  php-redis
1 upgraded, 0 newly installed, 0 to remove and 61 not upgraded.
Inst php-redis [3.1.1-1] (4.1.1-1+0~20180819152012.3+stretch~1.gbpd95942 Wikimedia:9/stretch-wikimedia [amd64])
Conf php-redis (4.1.1-1+0~20180819152012.3+stretch~1.gbpd95942 Wikimedia:9/stretch-wikimedia [amd64])

In T215376#4932577, @Reedy wrote:

In modules/contint/manifests/packages/php.pp we're doing ensure => latest

We should probably stop doing that. Surprise upgrades from "latest" have bitten us too much in the past.

In T215376#4932704, @Dzahn wrote:

In T215376#4932577, @Reedy wrote:

In modules/contint/manifests/packages/php.pp we're doing ensure => latest

We should probably stop doing that. Surprise upgrades from "latest" have bitten us too much in the past.

If we don't use latest, won't we instead be bitten quietly and gradually as new servers are brought online (or existing ones reimaged for whatever reason)? Is this sort of stuff tested for and caught more quickly when ops do manual package updates?

If we use "present" (and not a specific version or "latest" either) we would get whatever the latest version is at the moment of installing a new server. A change in version at the time of installing a new server would be more expected than one on a random Sunday?

Mentioned in SAL (#wikimedia-operations) [2019-02-08T15:10:55Z] <jijiki> Upgrading php-redis 4.1.1 to mwmaint1002 - T215376

Mentioned in SAL (#wikimedia-operations) [2019-02-08T15:33:36Z] <_joe_> apt-get upgrade on mwmaint2001 to fix the php installation T215376

`All the extensions were not upgraded at the time we did the 7.0 => 7.2 transition - my bad! Updating them manually was the only thing that was needed - we needed to update all of them and not just php-redis.

As for using ensure => latest, that would've broken our installation badly and is generally considered bad practice, and something we actively avoid doing in production, where we have centralized means to check and upgrade our debian packages.